idnits 2.17.1 draft-ietf-ips-iscsi-slp-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: ---------------------------------------------------------------------------- ** 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? ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 7 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 2002) is 8017 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'SLP' is mentioned on line 98, but not defined == Unused Reference: 'RFC2609' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'RFC3082' is defined on line 758, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2614 ** Downref: Normative reference to an Experimental RFC: RFC 3082 == Outdated reference: A later version (-20) exists of draft-ietf-ips-iscsi-08 -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM2' == Outdated reference: A later version (-10) exists of draft-ietf-ips-iscsi-name-disc-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ips-iscsi-name-disc (ref. 'NDT') == Outdated reference: A later version (-22) exists of draft-ietf-ips-isns-05 == Outdated reference: A later version (-12) exists of draft-ietf-ips-iscsi-boot-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-slp (ref. 'RSIP') == Outdated reference: A later version (-19) exists of draft-ietf-ips-security-04 Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Bakke 3 Cisco 4 Expires May 2002 5 Joe Czap 6 Jim Hafner 7 John Hufferd 8 Kaladhar Voruganti 9 IBM 10 Howard Hall 11 Pirus 12 Jack Harwood 13 EMC 14 Yaron Klein 15 Sanrad 16 Marjorie Krueger 17 HP 18 Lawrence Lamers 19 San Valley Systems 20 Todd Sperry 21 Adaptec 22 Joshua Tseng 23 Nishan 25 November 2001 27 Finding iSCSI Targets and Name Servers Using SLP 29 Status of this Memo 31 This document is an Internet-Draft and is in full conformance with 32 all provisions of Section 10 of RFC2026. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet- Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 Copyright Notice 51 Copyright (C) The Internet Society (2001). All Rights Reserved. 53 Abstract 55 The iSCSI protocol provides a way for hosts to access SCSI devices 56 over an IP network. This document defines the use of the Service 57 Location Protocol (SLP) by iSCSI hosts, devices, and management 58 services, along with the SLP service type templates that describe the 59 services they provide. 61 1. Acknowledgements 63 This draft was produced by the iSCSI Naming and Discovery team, 64 including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti 65 (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad), 66 Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry 67 (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran 68 (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt 69 Peterson (Caldera) and James Kempf (Sun) for reviewing the document 70 from an SLP perspective. 72 2. Introduction 74 iSCSI [iSCSI] is a protocol used to transport SCSI [SAM2] commands, 75 data, and status across an IP network. This protocol is connection- 76 oriented, and is currently defined over TCP. iSCSI uses a client- 77 server relationship. The client end of the connection is an 78 initiator, and sends SCSI commands; the server end of the connection 79 is called a target, and receives and executes the commands. 81 There are several methods an iSCSI initiator can use to find the 82 targets to which it should connect. Two of these methods can be 83 accomplished without the use of SLP: 85 - Each target and its address can be statically configured on the 86 initiator. 88 - Each address providing targets can be configured on the initiator; 89 iSCSI provides a mechanism by which the initiator can query the 90 address for a list of targets. 92 The above methods are further defined in "iSCSI Naming and Discovery 93 Requirements" [NDT]. 95 Each of the above methods requires a small amount of configuration to 96 be done on each initiator. The ability to discover targets and name 97 services without having to configure initiators is a desirable 98 feature. The Service Location Protocol (SLP) [SLP] is an IETF 99 standards track protocol that provides several features that will 100 simplify locating iSCSI services. This document describes how SLP 101 can be used in iSCSI environments to discover targets, addresses 102 providing targets, and storage management servers. 104 This draft is a work in progress. Searching for the string "WORK" in 105 this document should find anything that is not considered to be 106 complete. The following items are still open: 108 - Need to add RFC 3082 interaction. An initiator that is already up 109 and running must be notified within a reasonable amount of time 110 when a new target becomes available to it. This may be due to a 111 storage device booting, a network interface being added to the 112 device, a new target being created on the device, or the initiator 113 being added to the access-list of an existing device. Work is 114 under way to determine the best way to do this, either using the 115 experimental RFC 3082 or some modification thereof. Note that it 116 is a non-goal for SLP to notify an initiator when a target or one 117 of its service URLs is no longer accessible; the initiator will 118 find this out soon enough if it cares to attempt access to the 119 target. Note that RFC 3082 takes care of a device booting, adding 120 a new interface or target (and hence, a service URL), but not the 121 access-list change. 123 - Add comments about lifetime of URLs and how it is used. URLs are 124 registered with a finite lifetime. If the lifetime is too long, a 125 lot of stale URLs may hang around; if it is too short, SLP 126 participants will spend too much time re-registering the same old 127 URLs. There is a definite recommendation by the SLP folks to stick 128 with the default; I have to go look it up to see what it is. 130 - SLP can be set up to use either Unicast or Multicast. Add a 131 discussion on when to use each. 133 - Storage Name Service or Storage Management Service? Need to settle 134 on a generic name for things like this. 136 The following modifications have been made since draft-01: 138 - Removed the mgmt-ipaddress attribute from the template; if FQDN is 139 not available, the IP address may be returned in its place as a 140 dotted-decimal string. 142 - Added example for finding targets that will allow access to any 143 initiator. 145 - Updated Security Considerations to reference the IP storage 146 security draft. 148 3. Notation Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 4. Terminology 156 Here are some definitions that may aid readers that are unfamiliar 157 with either SLP, SCSI, or iSCSI. Some of these definitions have been 158 reproduced from [RFC2608] and "Finding an RSIP Server with SLP" 159 [RSIP]. 161 User Agent (UA) A process working on the client's behalf 162 to establish contact with some service. 163 The UA retrieves service information from 164 the Service Agents or Directory Agents. 166 Service Agent (SA) A process working on behalf of one or more 167 services to advertise the services and 168 their capabilites. 170 Directory Agent (DA) A process which collects service 171 advertisements. There can only be one DA 172 present per given host. 174 Scope A named set of services, typically making 175 up a logical administrative group. 177 Service Advertisement A URL, attributes, and a lifetime 178 (indicating how long the advertisement is 179 valid), providing service access 180 information and capabilities description 181 for a particular service. 183 Initiator A logical entity, typically within a host, 184 that sends SCSI commands to targets to be 185 executed. An initiator is usually present 186 in the form of a device driver. 188 Target A logical entity, typically within a 189 storage controller or gateway, that 190 receives SCSI commands from an initiator 191 and executes them. A target includes one 192 or more Logical Units (LUs); each LU is a 193 SCSI device, such as a disk or tape drive. 195 iSCSI Name A UTF-8 character string which serves as a 196 unique identifier for iSCSI initiators and 197 targets. Its format and usage is further 198 defined in [NDT]. 200 iSCSI Client A logical entity, typically a host, which 201 includes at least one iSCSI Initiator. 203 iSCSI Server A logical entity, typically a storage 204 controller or gateway, which includes at 205 least one iSCSI Target. 207 Storage Management Server An addressible entity that provides 208 management services that benefit an iSCSI 209 environment. "Storage management server" 210 is used as a generic term, rather than a 211 specific protocol or service. 213 5. Using SLP for iSCSI Service Discovery 215 Two entities are involved in iSCSI discovery. The end result is that 216 an iSCSI initiator (e.g. a host) discovers iSCSI targets, usually 217 provided by storage controllers or gateways. 219 iSCSI targets are registered with SLP as a set of service URLs, one 220 for each address on which the target may be accessed. Initiators 221 discover these targets using SLP service requests. Targets that do 222 not directly support SLP, or are under the control of a management 223 service, may be registered by a proxy service agent as part of the 224 software providing this service. 226 iSCSI entities may also use SLP to discover higher-level management 227 services where needed. 229 This section first describes the use of SLP for discovery of targets 230 by iSCSI initiators, and then describes the use of SLP to discover 231 storage management servers. 233 This document assumes that SLPv2 will be used when discovering iSCSI- 234 related services; no attempt is made to include support for SLPv1. 236 5.1. Discovering iSCSI Targets using SLP 238 The following diagram shows the relationship between iSCSI clients, 239 servers, initiators, and targets. An iSCSI client includes at least 240 one iSCSI initiator, and an SLP user agent (UA). An iSCSI server 241 includes at least one iSCSI target, and an SLP service agent (SA). 242 Some entities, such as extended copy engines, include both initiators 243 and targets. These include both an SA, for its targets to be 244 discovered, and a UA, for its intiator(s) to discover other targets. 246 +---------------------------------+ 247 | iSCSI Client | 248 | +-----------+ | 249 | | iSCSI | | 250 | | initiator | | 251 | | "myhost" | | 252 | +-----------+ | 253 | | 254 +--------------------------+------+ 255 | iSCSI Driver | UA | 256 +--------------------------+------+ 257 | TCP/UDP/IP | 258 +----------------+----------------+ 259 | Interface 1 | Interface 2 | 260 +----------------+----------------+ 261 | | 262 +------------+ | | +------------+ 263 | SLP DA | | | | SLP DA | 264 | (optional) |----+ IP Networks +----| (optional) | 265 +------------+ | | +------------+ 266 | | 267 +-----------------+-----------------| 268 | Interface 1 | Interface 2 | 269 | 10.1.30.21 | 10.1.40.3 | 270 +-----------------+-----------------+ 271 | TCP/UDP/IP | 272 +---------------------------+-------+ 273 | iSCSI Driver | SA | 274 +---------------------------+-------| 275 | | 276 | +--------+ +--------+ +---------+ | 277 | | iSCSI | | iSCSI | | iSCSI | | 278 | | target | | target | | target | | 279 | | "one" | | "two" | | "three" | | 280 | +--------+ +--------+ +---------+ | 281 | iSCSI Server | 282 +-----------------------------------+ 284 In the above drawing, the iSCSI server has three iSCSI targets that 285 the client could discover, named "one", "two" and "three". The iSCSI 286 client has an iSCSI initiator with the name "myhost". The iSCSI 287 client may use the initiator name in its SLP Service Requests as a 288 filter to discover only targets that are configured to accept iSCSI 289 connections from "myhost". 291 Each iSCSI target and initiator has a unique name, called an iSCSI 292 Name. This identifier is the same regardless of the network path 293 (through adapter cards, networks, interfaces on the storage device) 294 over which the target is discovered and accessed. For this example, 295 the iSCSI names "one" and "two", and "three" are used for the 296 targets; the initiator uses the name "myhost". An actual iSCSI name 297 would incorporate more structure, including a naming authority, and 298 is not described here. 300 Each of the iSCSI targets in the drawing can appear at two addresses, 301 since two network interfaces are present. Each target, would have 302 two service URLs. 304 An iSCSI target URL consists of its fully qualified host name or IP 305 address, the TCP port on which it is listening, and its iSCSI name. 306 An iSCSI server must register each of its individual targets at each 307 of its network addresses. 309 The iSCSI server constructs a service advertisement of the type 310 "service:iscsi:target" for each of the service URLs it wishes to 311 register. The advertisement contains a lifetime, along with other 312 attributes which are defined in the service template. 314 If the server in the above drawing is listening at TCP port 5003 for 315 both network addresses, the service URLs registered would be: 317 - 10.1.30.21:5003/one 319 - 10.1.30.21:5003/two 321 - 10.1.30.21:5003/three 323 - 10.1.40.3:5003/one 325 - 10.1.40.3:5003/two 327 - 10.1.40.3:5003/three 329 The remainder of the discovery procedure is identical to that used by 330 any client/server pair implementing SLP: 332 1. If an SLP DA is found, the SA contacts the DA and registers 333 the advertisement. If no DA is found, the SA maintains the 334 advertisement itself, answering multicast UA queries 335 directly. 337 2. When the iSCSI initiator requires contact information for an 338 iSCSI target, the UA either contacts the DA using unicast or 339 the SA using multicast. If a UA is configured with the address 340 of the SA, it may avoid multicast and contact an SA using 341 unicast. The UA includes a query based on 342 the attributes to indicate the characteristics of the 343 target(s) it requires. 345 3. Once the UA has the host name or address of the iSCSI server 346 as well as the port number and iSCSI Target Name, it can begin the 347 normal iSCSI login to the target. 349 As information contained in the iSCSI target template may exceed 350 common network datagram sizes, the SLP implementation for both UAs 351 and SAs supporting this template MUST implement SLP over TCP. 353 In some networks, the use of multicast for discovery purposes is 354 either unavailable or not allowed. Such networks include public or 355 service-provider networks that are placed in between an iSCSI client 356 and server; these are probably most common between two iSCSI 357 gateways, one at a storage service provider site, and one at a 358 customer site. 360 In these networks, an initiator may, instead or in addition to its DA 361 configuration, allow the addresses of one or more SAs to be 362 configured. The initiator would then make unicast SLP service 363 requests directly to these SAs, without the use of multicast to first 364 discover them. 366 This functionality is well within the scope of the current SLP 367 protocol. However, it does have two consequences for implementors: 369 - A service-agent responding to requests for iSCSI targets MUST 370 implement SLP over TCP; UDP only is not enough. 372 - An initiator configured to make direct, unicast requests to an 373 SA will have to add this to the SLP API, if it is following the 374 service location API defined in [RFC2614]. 376 5.2. Discovering Storage Management Services using SLP 378 Storage management servers can be built to manage and control access 379 to targets in a variety of ways. They can also provide extended 380 services beyond discovery, which could include storage allocation and 381 management. None of these services are defined here; the intent of 382 this document is to allow these services to be discovered by both 383 clients and servers, in addition to the target discovery already 384 being performed. 386 The following drawing shows an iSCSI client, an iSCSI server, and a 387 storage management server. To simplify the drawing, the second IP 388 network is not shown, but is assumed to exist. The storage 389 management server would use its own protocol (smsp) to provide 390 capabilities to iSCSI clients and servers; these clients and servers 391 can both use SLP to discover the storage management server. 393 +---------------------------+ 394 | iSCSI Client | 395 | | 396 | +-----------+ | 397 | | iSCSI | | 398 | | initiator | | 399 | +-----------+ | 400 | | 401 +---------------+------+----+ +------------+ 402 | iSCSI Driver | smsp | UA | | SLP DA | 403 +---------------+------+----+ | | 404 | TCP/UDP/IP | | (optional) | 405 +---------------+------+----+ +------------+ 406 | | 407 | IP Network | 408 ------------------------------------------ 409 | | 410 | | 411 +---------------+-----------+ +---------------------+ 412 | TCP/UDP/IP | | TCP/UDP/IP | 413 +---------------+------+----+ +---------------------+ 414 | iSCSI Driver | smsp | UA | | SA | smsp | 415 +---------------+------+----+ +---------------------+ 416 | | | | 417 | +--------+ +--------+ | | storage mgmt server | 418 | | iSCSI | | iSCSI | | | | 419 | | target | | target | | +---------------------+ 420 | | 1 | | 2 | | 421 | +--------+ +--------+ | 422 | | 423 | iSCSI Server | 424 +---------------------------+ 426 Note the difference between the storage management server model and 427 the previously-defined target discovery model. When target discovery 428 was used, the iSCSI Server implemented an SA, to be discovered by the 429 initiator's UA. In the storage management server model, the iSCSI 430 clients and servers both implement UAs, and the management server 431 implements the SA. 433 A storage management server's URL contains the domain name or IP 434 address and TCP port. No other information is required. 436 The storage management server constructs a service advertisement of 437 the type "service:iscsi:sms" for each of the addresses at which it 438 appears. The advertisement contains the URL, a lifetime, along with 439 other attributes which are defined in the service template. 441 The remainder of the discovery procedure is identical to that used to 442 discover iSCSI targets, except that both initiators and targets would 443 normally be "clients" of the storage management service. 445 Targets that support a storage management service implement a UA in 446 addition to the SA. A target may alternatively just implement the 447 UA, and allow the storage management service to advertise its targets 448 appropriately by providing an SA and registering the appropriate 449 service:iscsi:target registrations on the target's behalf; the target 450 device would not have to advertise its own targets. This has no 451 impact on the initiator. 453 This allows the initiators' discovery of targets to be completely 454 interoperable regardless of which storage management service is used, 455 or whether one is used at all, or whether the target registrations 456 are provided directly by the target or by the management service. 458 5.3. NAT and NAPT Considerations 460 Since SLP provides IP address and TCP port information within its 461 payload, the addresses an SA or DA advertise may not be the same as 462 those a UA must use if a Network Address(/Port) Translation 463 (NAT/NAPT) device is present between the UA and the SA. This may 464 result in the UA discovering address information that is unusable. 465 Here are a few recommendations to handle this: 467 - Use a fully-qualified domain name instead of IP address in service 468 URLs and in the mgmt-entity attribute. 470 - Stick with the default, IANA-assigned iSCSI TCP port number in 471 service URLs, wherever possible. 473 - If advertising service URLs through a NAT/NAPT device, and the 474 FQDN, IP address, or TCP port will be translated, the NAT/NAPT 475 device can provide an SLP proxy capability to do the translation. 477 5.4. Implementation Considerations 479 This section will answer common questions for those who are not too 480 familiar with SLP. 482 Where are the templates used? By the implementor; don't need to be 483 installed in a DA (not like a MIB). 485 Who makes use of the templates? 486 - Implementor of iSCSI host drivers / adapters / devices 487 - Network Administrator (DHCP and DA) 488 - Storage Administrator (DA and SA) 490 Integrating SLP DA or SA within a storage management server 492 When to use multicast and/or unicast 494 Using DHCP to bootstrap SLP discovery 496 6. iSCSI SLP Templates 498 Three templates are provided: an iSCSI target template, a management 499 service template, and an abstract template to encapsulate the two. 501 6.1. The iSCSI Abstract Service Type Template 503 This template defines the abstract service "service:iscsi". It is 504 used as a top-level service to encapsulate all other iSCSI-related 505 services. 507 Name of submitter: Mark Bakke 508 Language of service template: en 509 Security Considerations: 510 See the security considerations of the concrete service types. 512 Template Text: 513 -------------------------template begins here----------------------- 514 template-type=iscsi 516 template-version=0.1 518 template-description= 519 This is an abstract service type. The purpose of the iscsi 520 service type is to encompass all of the services used to support 521 the iSCSI protocol. 523 template-url-syntax= 524 url-path= ; Depends on the concrete service type. 526 --------------------------template ends here------------------------ 528 6.2. The iSCSI Target Concrete Service Type Template 530 This template defines the service "service:iscsi:target". An entity 531 containing iSCSI targets that wishes them discovered via SLP would 532 register each of them, with each of their addresses, as this service 533 type. 535 Initiators (and perhaps management services) wishing to discover 536 targets in this way will generally use one of the following queries: 538 1. Find a specific target, given its iSCSI Target Name: 540 Service: service:iscsi:target 541 Scope: initiator-scope-list 542 Query: (iscsi-name=iqn.2001-04.com.acme.sn.456) 544 2. Find all of the iSCSI Target Names that may allow access to a 545 given initiator: 547 Service: service:iscsi:target 548 Scope: initiator-scope-list 549 Query: (access-list=iqn.1998-03.com.os.hostid.045A7B) 551 3. Find all of the iSCSI Target Names that may allow access to 552 any initiator: 554 Service: service:iscsi:target 555 Scope: initiator-scope-list 556 Query: (access-list=iscsi) 558 4. Find the iSCSI Target Names from which the given initiator is 559 allowed to boot: 561 Service: service:iscsi:target 562 Scope: initiator-scope-list 563 Query: (boot-list=iqn.1998-03.com.os.hostid.045A7B) 565 5. In addition, a management service may wish to discover all 566 targets: 568 Service: service:iscsi:target 569 Scope: management-server-scope-list 570 Query: 572 More details on booting from an iSCSI target are defined in [BOOT]. 574 Name of submitter: Mark Bakke 575 Language of service template: en 576 Security Considerations: 577 See later section. 579 Template Text: 580 -------------------------template begins here----------------------- 581 template-type=iscsi:target 583 template-version=0.1 585 template-description= 586 This is concrete service type. The iscsi:target service type is used 587 to register individual target addresses to be discovered by others. 588 UAs will generally search for these by including one of the following: 589 - the iSCSI target name 590 - the iSCSI initiator name (must be in the access-list of the target) 591 - the service URL 593 template-url-syntax= 594 url-path = ipaddr [ : tcpport ] / iscsi-name 595 ipaddr = DNS host name or ip address 596 tcpport = decimal tcp port number 597 iscsi-name = iSCSI target name 598 ; The iscsi-name part of the URL is required and must be the iSCSI 599 ; name of the target being registered. 600 ; A device representing multiple targets must individually 601 ; register each target/address combination with SLP. 602 ; 603 ; Example: 604 ; service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678 606 iscsi-name = string 607 # The iSCSI Name of this target. 608 # This must match the iscsi-name in the url-path. 610 portal-group = integer 611 # The iSCSI portal group tag for this address. Addresses sharing 612 # the same iscsi-name and portal-group tag can be used within the 613 # same iSCSI session. Portal groups are described in [ISCSI]. 615 transports = string M L 616 tcp 617 # This is a list of transport protocols that the registered 618 # entity supports. iSCSI is currently supported over TCP, 619 # but it is anticipated that it could be supported over other 620 # transports, such as SCTP, in the future. 621 tcp 623 mgmt-entity = string O 624 # The fully qualified domain name, or IP address in dotted-decimal 625 # notation, of the management interface of the entity containing 626 # this target. 627 # 628 # WORK - Should this be a URL? 629 # snmp://10.1.1.1 630 # http://mydisk.ssp.com:1080/ 631 # telnet://mydisk.ssp.com 633 alias = string O 634 # The alias string contains a descriptive name of the target. 636 access-list = string M 637 # A list of iSCSI Initiator Names that can access this target. 638 # Normal iSCSI names will be 50 characters or less; max length is 255. 639 # Normally, only one or a few values will be in the list. 640 # Using the equivalence search on this will evaluate to "true" 641 # if any one of the items in this list matches the query. 642 # If this list contains the default name "iscsi", any initiator 643 # is allowed to access this target. 645 boot-list = string M O 646 # A list of iSCSI Initiator Names that can boot from this target. 647 # This list works precisely like the access-list attribute. A name appearing 648 # in this list must either appear in the access-list, or the 649 # access-list must contain the initiator name "iscsi". Otherwise, an 650 # initiator will be unable to find its boot target. 651 # If boot-list contains the name "iscsi", any host can boot from it, 652 # but I am not sure if this is useful to anyone. 653 # If this attribute is not registered, this target is not "bootable". 654 # 655 # Note that the LUN the host boots from is not specified here; a 656 # host will generally attempt to boot from LUN 0. 657 # 658 # It is quite possible that other attributes will need to be defined 659 # here for booting as well. 661 --------------------------template ends here------------------------ 663 6.3. iSCSI Storage Management Service Templates 665 This template defines the service "service:iscsi:sms". An entity 666 supporting one or more iSCSI management service protocols may 667 register itself with SLP as this service type. 669 iSCSI clients and servers wishing to discover storage management 670 services using SLP will usually search for them by the protocol(s) 671 they support: 673 Service: service:iscsi:sms 674 Scope: initiator-scope-list 675 Query: (protocols=isns) 677 Name of submitter: Mark Bakke 678 Language of service template: en 679 Security Considerations: 680 See later section. 682 Template Text: 683 -------------------------template begins here----------------------- 684 template-type=iscsi:sms 686 template-version=0.1 688 template-description= 689 This is a concrete service type. The iscsi:sms service type 690 provides the capability for entities supporting iSCSI to discover 691 appropriate management services. 693 template-url-syntax= 694 url-path = ; The URL of the management service. Defined in RFC 2608. 696 protocols = string M L 697 # The list of protocols supported by this name service. This 698 # list may be expanded in the future. There is no default. 699 # 700 # "isns" - This management service supports the use of the iSNS 701 # protocol for access management, health monitoring, and 702 # discovery management services. This protocol is defined 703 # in [ISNS]. 704 isns 706 --------------------------template ends here------------------------ 708 7. Security Considerations 710 Service type templates provide information that is used to interpret 711 information obtained by clients through SLP. If the iSCSI templates 712 are modified or if false templates are distributed, iSCSI targets and 713 name servers may not correctly register themselves, or iSCSI clients 714 may not be able to interpret service information. 716 SLP provides an authentication mechanism for UAs to assure that 717 service advertisments only come from trusted SAs. [RFC2608] If trust 718 is an issue, particularly with respect to the information sought by 719 the client about IPSEC and IKE support, then SLP authentication 720 should be enabled in the network. 722 Once a target or management server is discovered, authentication and 723 authorization are handled by the iSCSI protocol, or by the management 724 server's protocol. It is the responsibility of the providers of 725 these services to ensure that an inappropriately advertised or 726 discovered service does not compromise their security. 728 7.1. IPsec Integration 730 Although SLPv2 security provides authentication, it does not provide 731 confidentiality. 733 The use of IPsec and IKE for SLPv2 is discussed in [IPS-SEC], and is 734 a work in progress. It will be discussed further here in a 735 subsequent draft revision. 737 8. Summary 739 This document describes how SLP can be used by iSCSI initiators to 740 find iSCSI targets and storage management servers. Service type 741 templates for iSCSI targets and storage management servers are 742 presented. 744 9. References 746 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. Service 747 Location Protocol, version 2 RFC 2608, July 1999. 749 [RFC2609] E. Guttman, C. Perkins, J. Kempf. Service Templates and 750 service: Schemes RFC 2609, July 1999. 752 [RFC2614] J. Kempf, E. Guttman. An API for Service Location 753 RFC 2614, June 1999. 755 [RFC2119] S. Bradner. Key Words for Use in RFCs to Indicate 756 Requirement Levels. RFC 2119, March 1997. 758 [RFC3082] J. Kempf, J Goldschmidt. Notification and Subscription for 759 SLP. RFC 3082, March 2001. 761 [ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-08.txt, 762 September 2001. 764 [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. 766 [NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery", draft- 767 ietf-ips-iscsi-name-disc-03, July 2001. 769 [ISNS] J. Tseng, et. al. "Internet Storage Name Service", 770 draft-ietf-ips-isns-05, November 2001. 772 [BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for 773 Bootstrapping Clients using the iSCSI Protocol", 774 draft-ietf-ips-iscsi-boot-03, August 2001. 776 [RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with 777 SLP", draft-ietf-nat-rsip-slp-00, February 2000. 779 [IPS-SEC] B. Aboba, et. al., "Securing iSCSI, iFCP, and FCIP", 780 draft-ietf-ips-security-04, October 2001. 782 Author's Address: 784 Mark Bakke 785 Cisco Systems, Inc. 786 6450 Wedgwood Road 787 Maple Grove, MN 788 USA 55311 790 Voice: +1 763-398-1000 791 E-Mail: mbakke@cisco.com 793 Full Copyright Statement 795 Copyright (C) The Internet Society (2001). All Rights Reserved. 797 This document and translations of it may be copied and furnished to 798 others, and derivative works that comment on or otherwise explain it 799 or assist in its implementation may be prepared, copied, published 800 and distributed, in whole or in part, without restriction of any 801 kind, provided that the above copyright notice and this paragraph are 802 included on all such copies and derivative works. However, this 803 document itself may not be modified in any way, such as by removing 804 the copyright notice or references to the Internet Society or other 805 Internet organizations, except as needed for the purpose of 806 developing Internet standards in which case the procedures for 807 copyrights defined in the Internet Standards process must be 808 followed, or as required to translate it into languages other than 809 English. 811 The limited permissions granted above are perpetual and will not be 812 revoked by the Internet Society or its successors or assigns. 814 This document and the information contained herein is provided on an 815 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 816 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 817 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 818 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 819 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 821 Acknowledgement 823 Funding for the RFC Editor function is currently provided by the 824 Internet Society.