idnits 2.17.1 draft-ietf-ips-iscsi-slp-03.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 (September 2002) is 7893 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 765, but no explicit reference was found in the text == Unused Reference: 'RFC3082' is defined on line 777, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2614 == Outdated reference: A later version (-01) exists of draft-kempf-svrloc-rfc2614bis-00 -- Possible downref: Normative reference to a draft: ref. '2614BIS' ** Downref: Normative reference to an Experimental RFC: RFC 3082 == Outdated reference: A later version (-20) exists of draft-ietf-ips-iscsi-10 -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM2' == Outdated reference: A later version (-10) exists of draft-ietf-ips-iscsi-name-disc-05 ** 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-04 ** 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-10 == Outdated reference: A later version (-02) exists of draft-guttman-svrloc-serviceid-01 -- Possible downref: Normative reference to a draft: ref. 'SVCID' Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Bakke 3 Cisco 4 Expires September 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 March 2002 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 - Should look into Erik Guttman's serviceid scheme [SVCID] as a 109 slight variation to our SLP template, and see what it would take to 110 implement it, and whether it would change APIs. 112 - Need to add RFC 3082 interaction. An initiator that is already up 113 and running must be notified within a reasonable amount of time 114 when a new target becomes available to it. This may be due to a 115 storage device booting, a network interface being added to the 116 device, a new target being created on the device, or the initiator 117 being added to the access-list of an existing device. Work is 118 under way to determine the best way to do this, either using the 119 experimental RFC 3082 or some modification thereof. Note that it 120 is a non-goal for SLP to notify an initiator when a target or one 121 of its service URLs is no longer accessible; the initiator will 122 find this out soon enough if it cares to attempt access to the 123 target. Note that RFC 3082 takes care of a device booting, adding 124 a new interface or target (and hence, a service URL), but not the 125 access-list change. 127 - Add comments about lifetime of URLs and how it is used. URLs are 128 registered with a finite lifetime. If the lifetime is too long, a 129 lot of stale URLs may hang around; if it is too short, SLP 130 participants will spend too much time re-registering the same old 131 URLs. There is a definite recommendation by the SLP folks to stick 132 with the default; I have to go look it up to see what it is. 134 - SLP can be set up to use either Unicast or Multicast. Add a 135 discussion on when to use each. 137 The following modifications have been made in draft-02: 139 - Removed the mgmt-ipaddress attribute from the template; if FQDN is 140 not available, the IP address may be returned in its place as a 141 dotted-decimal string. 143 - Added example for finding targets that will allow access to any 144 initiator. 146 - Updated Security Considerations to reference the IP storage 147 security draft. 148 The following modifications were made in draft-03: 150 - Updated non-multicast usage text in section 5.1. 152 - Updated references. 154 3. Notation Conventions 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 4. Terminology 162 Here are some definitions that may aid readers that are unfamiliar 163 with either SLP, SCSI, or iSCSI. Some of these definitions have been 164 reproduced from [RFC2608] and "Finding an RSIP Server with SLP" 165 [RSIP]. 167 User Agent (UA) A process working on the client's behalf 168 to establish contact with some service. 169 The UA retrieves service information from 170 the Service Agents or Directory Agents. 172 Service Agent (SA) A process working on behalf of one or more 173 services to advertise the services and 174 their capabilites. 176 Directory Agent (DA) A process which collects service 177 advertisements. There can only be one DA 178 present per given host. 180 Scope A named set of services, typically making 181 up a logical administrative group. 183 Service Advertisement A URL, attributes, and a lifetime 184 (indicating how long the advertisement is 185 valid), providing service access 186 information and capabilities description 187 for a particular service. 189 Initiator A logical entity, typically within a host, 190 that sends SCSI commands to targets to be 191 executed. An initiator is usually present 192 in the form of a device driver. 194 Target A logical entity, typically within a 195 storage controller or gateway, that 196 receives SCSI commands from an initiator 197 and executes them. A target includes one 198 or more Logical Units (LUs); each LU is a 199 SCSI device, such as a disk or tape drive. 201 iSCSI Name A UTF-8 character string which serves as a 202 unique identifier for iSCSI initiators and 203 targets. Its format and usage is further 204 defined in [NDT]. 206 iSCSI Client A logical entity, typically a host, which 207 includes at least one iSCSI Initiator. 209 iSCSI Server A logical entity, typically a storage 210 controller or gateway, which includes at 211 least one iSCSI Target. 213 Storage Management Server An addressible entity that provides 214 management services that benefit an iSCSI 215 environment. "Storage management server" 216 is used as a generic term, rather than a 217 specific protocol or service. 219 5. Using SLP for iSCSI Service Discovery 221 Two entities are involved in iSCSI discovery. The end result is that 222 an iSCSI initiator (e.g. a host) discovers iSCSI targets, usually 223 provided by storage controllers or gateways. 225 iSCSI targets are registered with SLP as a set of service URLs, one 226 for each address on which the target may be accessed. Initiators 227 discover these targets using SLP service requests. Targets that do 228 not directly support SLP, or are under the control of a management 229 service, may be registered by a proxy service agent as part of the 230 software providing this service. 232 iSCSI entities may also use SLP to discover higher-level management 233 services where needed. 235 This section first describes the use of SLP for discovery of targets 236 by iSCSI initiators, and then describes the use of SLP to discover 237 storage management servers. 239 This document assumes that SLPv2 will be used when discovering iSCSI- 240 related services; no attempt is made to include support for SLPv1. 242 5.1. Discovering iSCSI Targets using SLP 244 The following diagram shows the relationship between iSCSI clients, 245 servers, initiators, and targets. An iSCSI client includes at least 246 one iSCSI initiator, and an SLP user agent (UA). An iSCSI server 247 includes at least one iSCSI target, and an SLP service agent (SA). 248 Some entities, such as extended copy engines, include both initiators 249 and targets. These include both an SA, for its targets to be 250 discovered, and a UA, for its intiator(s) to discover other targets. 252 +---------------------------------+ 253 | iSCSI Client | 254 | +-----------+ | 255 | | iSCSI | | 256 | | initiator | | 257 | | "myhost" | | 258 | +-----------+ | 259 | | 260 +--------------------------+------+ 261 | iSCSI Driver | UA | 262 +--------------------------+------+ 263 | TCP/UDP/IP | 264 +----------------+----------------+ 265 | Interface 1 | Interface 2 | 266 +----------------+----------------+ 267 | | 268 +------------+ | | +------------+ 269 | SLP DA | | | | SLP DA | 270 | (optional) |----+ IP Networks +----| (optional) | 271 +------------+ | | +------------+ 272 | | 273 +-----------------+-----------------| 274 | Interface 1 | Interface 2 | 275 | 10.1.30.21 | 10.1.40.3 | 276 +-----------------+-----------------+ 277 | TCP/UDP/IP | 278 +---------------------------+-------+ 279 | iSCSI Driver | SA | 280 +---------------------------+-------| 281 | | 282 | +--------+ +--------+ +---------+ | 283 | | iSCSI | | iSCSI | | iSCSI | | 284 | | target | | target | | target | | 285 | | "one" | | "two" | | "three" | | 286 | +--------+ +--------+ +---------+ | 287 | iSCSI Server | 288 +-----------------------------------+ 290 In the above drawing, the iSCSI server has three iSCSI targets that 291 the client could discover, named "one", "two" and "three". The iSCSI 292 client has an iSCSI initiator with the name "myhost". The iSCSI 293 client may use the initiator name in its SLP Service Requests as a 294 filter to discover only targets that are configured to accept iSCSI 295 connections from "myhost". 297 Each iSCSI target and initiator has a unique name, called an iSCSI 298 Name. This identifier is the same regardless of the network path 299 (through adapter cards, networks, interfaces on the storage device) 300 over which the target is discovered and accessed. For this example, 301 the iSCSI names "one" and "two", and "three" are used for the 302 targets; the initiator uses the name "myhost". An actual iSCSI name 303 would incorporate more structure, including a naming authority, and 304 is not described here. 306 Each of the iSCSI targets in the drawing can appear at two addresses, 307 since two network interfaces are present. Each target, would have 308 two service URLs. 310 An iSCSI target URL consists of its fully qualified host name or IP 311 address, the TCP port on which it is listening, and its iSCSI name. 312 An iSCSI server must register each of its individual targets at each 313 of its network addresses. 315 The iSCSI server constructs a service advertisement of the type 316 "service:iscsi:target" for each of the service URLs it wishes to 317 register. The advertisement contains a lifetime, along with other 318 attributes which are defined in the service template. 320 If the server in the above drawing is listening at TCP port 5003 for 321 both network addresses, the service URLs registered would be: 323 - 10.1.30.21:5003/one 325 - 10.1.30.21:5003/two 327 - 10.1.30.21:5003/three 329 - 10.1.40.3:5003/one 331 - 10.1.40.3:5003/two 333 - 10.1.40.3:5003/three 335 The remainder of the discovery procedure is identical to that used by 336 any client/server pair implementing SLP: 338 1. If an SLP DA is found, the SA contacts the DA and registers 339 the advertisement. If no DA is found, the SA maintains the 340 advertisement itself, answering multicast UA queries 341 directly. 343 2. When the iSCSI initiator requires contact information for an 344 iSCSI target, the UA either contacts the DA using unicast or 345 the SA using multicast. If a UA is configured with the address 346 of the SA, it may avoid multicast and contact an SA using 347 unicast. The UA includes a query based on 348 the attributes to indicate the characteristics of the 349 target(s) it requires. 351 3. Once the UA has the host name or address of the iSCSI server 352 as well as the port number and iSCSI Target Name, it can begin the 353 normal iSCSI login to the target. 355 As information contained in the iSCSI target template may exceed 356 common network datagram sizes, the SLP implementation for both UAs 357 and SAs supporting this template MUST implement SLP over TCP. 359 5.1.1. Using SLP in a Non-Multicast Environment 361 In some networks, the use of multicast for discovery purposes is 362 either unavailable or not allowed. Such networks include public or 363 service-provider networks that are placed in between an iSCSI client 364 and server; these are probably most common between two iSCSI 365 gateways, one at a storage service provider site, and one at a 366 customer site. 368 In these networks, an initiator may, instead or in addition to its DA 369 configuration, allow the addresses of one or more SAs to be 370 configured. The initiator would then make unicast SLP service 371 requests directly to these SAs, without the use of multicast to first 372 discover them. 374 This functionality is well within the scope of the current SLP 375 protocol. However, it does have two consequences for implementors: 377 - A service-agent responding to requests for iSCSI targets MUST 378 implement SLP over TCP; UDP only is not enough. This is not 379 an issue, since TCP is a requirement for iSCSI implementations 380 that use SLP for other reasons. 382 - An initiator configured to make direct, unicast requests to an 383 SA will have to add this to the SLP API, if it is following the 384 service location API defined in [RFC2614]. This capability 385 is being added to the next revision of the API, in [2614BIS]. 387 5.2. Discovering Storage Management Services using SLP 389 Storage management servers can be built to manage and control access 390 to targets in a variety of ways. They can also provide extended 391 services beyond discovery, which could include storage allocation and 392 management. None of these services are defined here; the intent of 393 this document is to allow these services to be discovered by both 394 clients and servers, in addition to the target discovery already 395 being performed. 397 The following drawing shows an iSCSI client, an iSCSI server, and a 398 storage management server. To simplify the drawing, the second IP 399 network is not shown, but is assumed to exist. The storage 400 management server would use its own protocol (smsp) to provide 401 capabilities to iSCSI clients and servers; these clients and servers 402 can both use SLP to discover the storage management server. 404 +---------------------------+ 405 | iSCSI Client | 406 | | 407 | +-----------+ | 408 | | iSCSI | | 409 | | initiator | | 410 | +-----------+ | 411 | | 412 +---------------+------+----+ +------------+ 413 | iSCSI Driver | smsp | UA | | SLP DA | 414 +---------------+------+----+ | | 415 | TCP/UDP/IP | | (optional) | 416 +---------------+------+----+ +------------+ 417 | | 418 | IP Network | 419 ------------------------------------------ 420 | | 421 | | 422 +---------------+-----------+ +---------------------+ 423 | TCP/UDP/IP | | TCP/UDP/IP | 424 +---------------+------+----+ +---------------------+ 425 | iSCSI Driver | smsp | UA | | SA | smsp | 426 +---------------+------+----+ +---------------------+ 427 | | | | 428 | +--------+ +--------+ | | storage mgmt server | 429 | | iSCSI | | iSCSI | | | | 430 | | target | | target | | +---------------------+ 431 | | 1 | | 2 | | 432 | +--------+ +--------+ | 433 | | 434 | iSCSI Server | 435 +---------------------------+ 437 Note the difference between the storage management server model and 438 the previously-defined target discovery model. When target discovery 439 was used, the iSCSI Server implemented an SA, to be discovered by the 440 initiator's UA. In the storage management server model, the iSCSI 441 clients and servers both implement UAs, and the management server 442 implements the SA. 444 A storage management server's URL contains the domain name or IP 445 address and TCP port. No other information is required. 447 The storage management server constructs a service advertisement of 448 the type "service:iscsi:sms" for each of the addresses at which it 449 appears. The advertisement contains the URL, a lifetime, along with 450 other attributes which are defined in the service template. 452 The remainder of the discovery procedure is identical to that used to 453 discover iSCSI targets, except that both initiators and targets would 454 normally be "clients" of the storage management service. 456 Targets that support a storage management service implement a UA in 457 addition to the SA. A target may alternatively just implement the 458 UA, and allow the storage management service to advertise its targets 459 appropriately by providing an SA and registering the appropriate 460 service:iscsi:target registrations on the target's behalf; the target 461 device would not have to advertise its own targets. This has no 462 impact on the initiator. 464 This allows the initiators' discovery of targets to be completely 465 interoperable regardless of which storage management service is used, 466 or whether one is used at all, or whether the target registrations 467 are provided directly by the target or by the management service. 469 5.3. NAT and NAPT Considerations 471 Since SLP provides IP address and TCP port information within its 472 payload, the addresses an SA or DA advertise may not be the same as 473 those a UA must use if a Network Address(/Port) Translation 474 (NAT/NAPT) device is present between the UA and the SA. This may 475 result in the UA discovering address information that is unusable. 476 Here are a few recommendations to handle this: 478 - Use a fully-qualified domain name instead of IP address in service 479 URLs and in the mgmt-entity attribute. 481 - Stick with the default, IANA-assigned iSCSI TCP port number in 482 service URLs, wherever possible. 484 - If advertising service URLs through a NAT/NAPT device, and the 485 FQDN, IP address, or TCP port will be translated, the NAT/NAPT 486 device can provide an SLP proxy capability to do the translation. 488 5.4. Implementation Considerations 490 This section will answer common questions for those who are not too 491 familiar with SLP. 493 Where are the templates used? By the implementor; don't need to be 494 installed in a DA (not like a MIB). 496 Who makes use of the templates? 497 - Implementor of iSCSI host drivers / adapters / devices 498 - Network Administrator (DHCP and DA) 499 - Storage Administrator (DA and SA) 501 WORK - Integrating SLP DA or SA within a storage management server 503 WORK - When to use multicast and/or unicast 505 WORK - Using DHCP to bootstrap SLP discovery 507 6. iSCSI SLP Templates 509 Three templates are provided: an iSCSI target template, a management 510 service template, and an abstract template to encapsulate the two. 512 6.1. The iSCSI Abstract Service Type Template 514 This template defines the abstract service "service:iscsi". It is 515 used as a top-level service to encapsulate all other iSCSI-related 516 services. 518 Name of submitter: Mark Bakke 519 Language of service template: en 520 Security Considerations: 521 See the security considerations of the concrete service types. 523 Template Text: 524 -------------------------template begins here----------------------- 525 template-type=iscsi 527 template-version=0.1 529 template-description= 530 This is an abstract service type. The purpose of the iscsi 531 service type is to encompass all of the services used to support 532 the iSCSI protocol. 534 template-url-syntax= 535 url-path= ; Depends on the concrete service type. 537 --------------------------template ends here------------------------ 539 6.2. The iSCSI Target Concrete Service Type Template 541 This template defines the service "service:iscsi:target". An entity 542 containing iSCSI targets that wishes them discovered via SLP would 543 register each of them, with each of their addresses, as this service 544 type. 546 Initiators (and perhaps management services) wishing to discover 547 targets in this way will generally use one of the following queries: 549 1. Find a specific target, given its iSCSI Target Name: 551 Service: service:iscsi:target 552 Scope: initiator-scope-list 553 Query: (iscsi-name=iqn.2001-04.com.acme.sn.456) 555 2. Find all of the iSCSI Target Names that may allow access to a 556 given initiator: 558 Service: service:iscsi:target 559 Scope: initiator-scope-list 560 Query: (access-list=iqn.1998-03.com.os.hostid.045A7B) 562 3. Find all of the iSCSI Target Names that may allow access to 563 any initiator: 565 Service: service:iscsi:target 566 Scope: initiator-scope-list 567 Query: (access-list=iscsi) 569 4. Find the iSCSI Target Names from which the given initiator is 570 allowed to boot: 572 Service: service:iscsi:target 573 Scope: initiator-scope-list 574 Query: (boot-list=iqn.1998-03.com.os.hostid.045A7B) 576 5. In addition, a management service may wish to discover all 577 targets: 579 Service: service:iscsi:target 580 Scope: management-server-scope-list 581 Query: 583 More details on booting from an iSCSI target are defined in [BOOT]. 585 Name of submitter: Mark Bakke 586 Language of service template: en 587 Security Considerations: 588 See later section. 590 Template Text: 591 -------------------------template begins here----------------------- 592 template-type=iscsi:target 594 template-version=0.1 596 template-description= 597 This is concrete service type. The iscsi:target service type is used 598 to register individual target addresses to be discovered by others. 599 UAs will generally search for these by including one of the following: 600 - the iSCSI target name 601 - the iSCSI initiator name (must be in the access-list of the target) 602 - the service URL 604 template-url-syntax= 605 url-path = ipaddr [ : tcpport ] / iscsi-name 606 ipaddr = DNS host name or ip address 607 tcpport = decimal tcp port number 608 iscsi-name = iSCSI target name 609 ; The iscsi-name part of the URL is required and must be the iSCSI 610 ; name of the target being registered. 611 ; A device representing multiple targets must individually 612 ; register each target/address combination with SLP. 613 ; 614 ; Example: 615 ; service:iscsi:target://10.1.3.40:5003/iqn.2001-04.com.acme.sn.45678 617 iscsi-name = string 618 # The iSCSI Name of this target. 619 # This must match the iscsi-name in the url-path. 621 portal-group = integer 622 # The iSCSI portal group tag for this address. Addresses sharing 623 # the same iscsi-name and portal-group tag can be used within the 624 # same iSCSI session. Portal groups are described in [ISCSI]. 626 transports = string M L 627 tcp 628 # This is a list of transport protocols that the registered 629 # entity supports. iSCSI is currently supported over TCP, 630 # but it is anticipated that it could be supported over other 631 # transports, such as SCTP, in the future. 632 tcp 634 mgmt-entity = string O 635 # The fully qualified domain name, or IP address in dotted-decimal 636 # notation, of the management interface of the entity containing 637 # this target. 638 # 640 alias = string O 641 # The alias string contains a descriptive name of the target. 643 access-list = string M 644 # A list of iSCSI Initiator Names that can access this target. 645 # Normal iSCSI names will be 50 characters or less; max length is 255. 646 # Normally, only one or a few values will be in the list. 647 # Using the equivalence search on this will evaluate to "true" 648 # if any one of the items in this list matches the query. 649 # If this list contains the default name "iscsi", any initiator 650 # is allowed to access this target. 652 boot-list = string M O 653 # A list of iSCSI Initiator Names that can boot from this target. 654 # This list works precisely like the access-list attribute. A name appearing 655 # in this list must either appear in the access-list, or the 656 # access-list must contain the initiator name "iscsi". Otherwise, an 657 # initiator will be unable to find its boot target. 658 # If boot-list contains the name "iscsi", any host can boot from it, 659 # but I am not sure if this is useful to anyone. 660 # If this attribute is not registered, this target is not "bootable". 661 # 662 # Note that the LUN the host boots from is not specified here; a 663 # host will generally attempt to boot from LUN 0. 664 # 665 # It is quite possible that other attributes will need to be defined 666 # here for booting as well. 668 --------------------------template ends here------------------------ 670 6.3. iSCSI Storage Management Service Templates 672 This template defines the service "service:iscsi:sms". An entity 673 supporting one or more iSCSI management service protocols may 674 register itself with SLP as this service type. 676 iSCSI clients and servers wishing to discover storage management 677 services using SLP will usually search for them by the protocol(s) 678 they support: 680 Service: service:iscsi:sms 681 Scope: initiator-scope-list 682 Query: (protocols=isns) 684 Name of submitter: Mark Bakke 685 Language of service template: en 686 Security Considerations: 687 See later section. 689 Template Text: 690 -------------------------template begins here----------------------- 691 template-type=iscsi:sms 693 template-version=0.1 695 template-description= 696 This is a concrete service type. The iscsi:sms service type 697 provides the capability for entities supporting iSCSI to discover 698 appropriate management services. 700 template-url-syntax= 701 url-path = ; The URL of the management service. Defined in RFC 2608. 703 protocols = string M L 704 # The list of protocols supported by this name service. This 705 # list may be expanded in the future. There is no default. 706 # 707 # "isns" - This management service supports the use of the iSNS 708 # protocol for access management, health monitoring, and 709 # discovery management services. This protocol is defined 710 # in [ISNS]. 711 isns 713 --------------------------template ends here------------------------ 715 7. Security Considerations 717 Service type templates provide information that is used to interpret 718 information obtained by clients through SLP. If the iSCSI templates 719 are modified or if false templates are distributed, iSCSI targets and 720 name servers may not correctly register themselves, or iSCSI clients 721 may not be able to interpret service information. 723 SLP provides an authentication mechanism for UAs to assure that 724 service advertisments only come from trusted SAs [RFC2608]. If trust 725 is an issue then SLP authentication should be enabled in the network. 727 Once a target or management server is discovered, authentication and 728 authorization are handled by the iSCSI protocol, or by the management 729 server's protocol. It is the responsibility of the providers of 730 these services to ensure that an inappropriately advertised or 731 discovered service does not compromise their security. 733 7.1. IPsec Integration 735 Although SLPv2 security provides authentication, it does not provide 736 confidentiality. In many environments, confidentiality of discovery 737 information is important. For instance, the existence of a 738 particular iSCSI target name within a building can indicate that 739 there is an expensive/important piece of equipment in there, and its 740 discovery information. This may provide enough information for an 741 attacker to attempt a denial-of-service or other attacks on the iSCSI 742 device. 744 SLPv2 authentication does not provide confidentiality of discovery 745 information. When this is a concern, in particular when SLPv2 is 746 used to distribute security policy information, IPsec MUST be used 747 with SLPv2 when discovering iSCSI targets. When this is not a 748 concern, SLPv2 security MAY be implemented and used. 750 The use of IPsec and IKE for SLPv2 is described in [IPS-SEC], and is 751 a work in progress. 753 8. Summary 755 This document describes how SLP can be used by iSCSI initiators to 756 find iSCSI targets and storage management servers. Service type 757 templates for iSCSI targets and storage management servers are 758 presented. 760 9. References 762 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service 763 Location Protocol, version 2", RFC 2608, July 1999. 765 [RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and 766 service: Schemes", RFC 2609, July 1999. 768 [RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC 769 2614, June 1999. 771 [2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft- 772 kempf-svrloc-rfc2614bis-00.txt, February 2002. 774 [RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate 775 Requirement Levels", RFC 2119, March 1997. 777 [RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for 778 SLP", RFC 3082, March 2001. 780 [ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-10.txt, 781 January 2002. 783 [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. 785 [NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery", draft- 786 ietf-ips-iscsi-name-disc-05, March 2002. 788 [ISNS] J. Tseng, et. al. "Internet Storage Name Service", 789 draft-ietf-ips-isns-05, November 2001. 791 [BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for 792 Bootstrapping Clients using the iSCSI Protocol", 793 draft-ietf-ips-iscsi-boot-04, November 2001. 795 [RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with 796 SLP", draft-ietf-nat-rsip-slp-00, February 2000. 798 [IPS-SEC] B. Aboba, et. al., "Securing iSCSI, iFCP, and FCIP", 799 draft-ietf-ips-security-10, February 2002. 801 [SVCID] E. Guttman, "The serviceid: URL Scheme for Service 802 Location", 803 draft-guttman-svrloc-serviceid-01, January 2002. 805 Author's Address: 807 Mark Bakke 808 Cisco Systems, Inc. 809 6450 Wedgwood Road 810 Maple Grove, MN 811 USA 55311 813 Voice: +1 763-398-1000 814 E-Mail: mbakke@cisco.com 816 Full Copyright Statement 818 Copyright (C) The Internet Society (2001). All Rights Reserved. 820 This document and translations of it may be copied and furnished to 821 others, and derivative works that comment on or otherwise explain it 822 or assist in its implementation may be prepared, copied, published 823 and distributed, in whole or in part, without restriction of any 824 kind, provided that the above copyright notice and this paragraph are 825 included on all such copies and derivative works. However, this 826 document itself may not be modified in any way, such as by removing 827 the copyright notice or references to the Internet Society or other 828 Internet organizations, except as needed for the purpose of 829 developing Internet standards in which case the procedures for 830 copyrights defined in the Internet Standards process must be 831 followed, or as required to translate it into languages other than 832 English. 834 The limited permissions granted above are perpetual and will not be 835 revoked by the Internet Society or its successors or assigns. 837 This document and the information contained herein is provided on an 838 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 839 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 840 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 841 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 842 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 844 Acknowledgement 846 Funding for the RFC Editor function is currently provided by the 847 Internet Society.