idnits 2.17.1 draft-ietf-ips-iscsi-slp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 10 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8229 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 112, but not defined == Unused Reference: 'RFC2609' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'ISCSI' is defined on line 673, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-ips-iscsi-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'SAM2' == Outdated reference: A later version (-10) exists of draft-ietf-ips-iscsi-name-disc-01 ** 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-00 == Outdated reference: A later version (-12) exists of draft-ietf-ips-iscsi-boot-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-slp (ref. 'RSIP') Summary: 8 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 October 2001 5 Joe Czap 6 IBM 8 Jim Hafner 9 IBM 11 Howard Hall 12 Pirus 14 Jack Harwood 15 EMC 17 John Hufferd 18 IBM 20 Yaron Klein 21 Sanrad 23 Lawrence Lamers 24 San Valley Systems 26 Todd Sperry 27 Adaptec 29 Joshua Tseng 30 Nishan 32 Kaladhar Voruganti 33 IBM 35 April 2001 37 Finding iSCSI Targets and Name Servers Using SLP 39 Status of this Memo 41 This document is an Internet-Draft and is in full conformance with 42 all provisions of Section 10 of RFC2026. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet- Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 Copyright Notice 62 Copyright (C) The Internet Society (2001). All Rights Reserved. 64 Abstract 66 The iSCSI protocol provides a way for hosts to access SCSI devices 67 over an IP network. This document defines the use of the Service 68 Location Protocol (SLP) by iSCSI hosts, devices, and name services, 69 along with the SLP service type templates that describe the services 70 they provide. 72 1. Acknowledgements 74 This draft was produced as a companion document for the iSCSI Naming 75 and Discovery team, including Joe Czap, Jim Hafner, John Hufferd, and 76 Kaladhar Voruganti (IBM), Howard Hall (Pirus), Jack Hardwood (EMC), 77 Yaron Klein (Sanrad), Lawrence Lamers (San Valley), Todd Sperry 78 (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran 79 (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt 80 Peterson (Caldera) and James Kempf (Sun) for reviewing the document 81 from an SLP perspective. 83 2. Introduction 85 iSCSI [iSCSI] is a protocol used to transport SCSI [SAM2] commands, 86 data, and status across an IP network. This protocol is connection- 87 oriented, and is currently defined over TCP. iSCSI uses a client- 88 server relationship. The client end of the connection is an 89 initiator, and sends SCSI commands; the server end of the connection 90 is called a target, and receives and executes the commands. 92 There are several methods an iSCSI initiator can use to find the 93 targets to which it should connect. The discovery of iSCSI targets 94 can be configured on the initiator in several ways: 96 - Each target and its address can be statically configured on the 97 initiator. 99 - Each address providing targets can be configured on the initiator; 100 the initiator can query the address for a list of targets. 102 - A storage name server address can be configured on the initiator; 103 the initiator can use the storage name servers's protocol it 104 provides to obtain a list of targets. 106 These methods are further defined in "iSCSI Naming and Discovery 107 Requirements" [NDT]. 109 Each of the above methods requires a small amount of configuration to 110 be done on each initiator. The ability to discover targets and name 111 services without having to configure initiators is a desirable 112 feature. The Service Location Protocol (SLP) [SLP] is an IETF 113 standards track protocol that provides several features that will 114 simplify locating iSCSI services. This document describes how SLP 115 can be used in iSCSI environments to discover targets, addresses 116 providing targets, and storage name servers. 118 3. Notation Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 4. Terminology 126 Here are some definitions that may aid readers that are unfamiliar 127 with either SLP, SCSI, or iSCSI. Some of these definitions have been 128 reproduced from [RFC2608] and "Finding an RSIP Server with SLP" 129 [RSIP]. 131 User Agent (UA) A process working on the client's behalf to 132 establish contact with some service. The UA 133 retrieves service information from the Service 134 Agents or Directory Agents. 136 Service Agent (SA) A process working on behalf of one or more 137 services to advertise the services and their 138 capabilites. 140 Directory Agent (DA) A process which collects service 141 advertisements. There can only be one DA 142 present per given host. 144 Scope A named set of services, typically making up a 145 logical administrative group. 147 Service Advertisement A URL, attributes, and a lifetime (indicating 148 how long the advertisement is valid), providing 149 service access information and capabilities 150 description for a particular service. 152 Initiator A logical entity, typically within a host, that 153 sends SCSI commands to targets to be executed. 154 An initiator is usually present in the form of 155 a device driver. 157 Target A logical entity, typically within a storage 158 controller or gateway, that receives SCSI 159 commands from an initiator and executes them. 160 A target includes one or more Logical Units 161 (LUs); each LU is a SCSI device, such as a disk 162 or tape drive. 164 iSCSI Name A UTF-8 character string which serves as a 165 unique identifier for iSCSI initiators and 166 targets. Its format and usage is further 167 defined in [NDT]. 169 iSCSI Client A logical entity, typically a host, which 170 includes at least one iSCSI Initiator. 172 iSCSI Server A logical entity, typically a storage 173 controller or gateway, which includes at least 174 one iSCSI Target. 176 Storage Name Server An addressible entity that provides one of 177 several discovery and management services that 178 benefit an iSCSI environment. Storage Name 179 Server is used as a generic term, and is not 180 necessarily equivalent to that used within 181 Fibre Channel. 183 5. Using SLP for iSCSI Service Discovery 185 At least two entities are involved in iSCSI discovery. The end 186 result is that an iSCSI initiator (e.g. a host) discovers iSCSI 187 targets, usually provided by storage controllers or gateways. An 188 iSCSI initiator may either discover these targets directly, using 189 SLP, or may opt to discover them through a storage name service. One 190 name service protocol currently under development is iSNS [ISNS]. In 191 the first case, only SLP is needed. In the second, SLP may be used 192 to discover a name server, which can be used to provide additional 193 capabilities beyond simple target discovery. 195 This section first describes the use of SLP for discovery of targets 196 by iSCSI initiators, and then describes the use of SLP to discover 197 storage name servers. 199 This document assumes that SLPv2 will be used when discovering iSCSI- 200 related services; no attempt is made to include support for SLPv1. 202 5.1. Discovering iSCSI Targets using SLP 204 The following diagram shows the relationship between iSCSI clients, 205 servers, initiators, and targets. An iSCSI client includes at least 206 one iSCSI initiator, and an SLP user agent (UA). An iSCSI server 207 includes at least one iSCSI target, and an SLP service agent (SA). 208 Some entities, such as extended copy engines, include both initiators 209 and targets. These include both an SA, for its targets to be 210 discovered, and a UA, for its intiator(s) to discover other targets. 211 +---------------------------------+ 212 | iSCSI Client | 213 | | 214 | +-----------+ | 215 | | iSCSI | | 216 | | initiator | | 217 | +-----------+ | 218 | | 219 +--------------------------+------+ 220 | iSCSI Driver | UA | 221 +--------------------------+------+ 222 | TCP/UDP/IP | 223 +----------------+----------------+ 224 | Interface 1 | Interface 2 | 225 +----------------+----------------+ 226 | | 227 +------------+ | | +------------+ 228 | SLP DA | | | | SLP DA | 229 | |----+ IP Networks +----| | 230 | (optional) | | | | (optional) | 231 +------------+ | | +------------+ 232 | | 233 +-----------------+-----------------| 234 | Interface 1 | Interface 2 | 235 | 10.1.30.21 | 10.1.40.3 | 236 +-----------------+-----------------+ 237 | TCP/UDP/IP | 238 +---------------------------+-------+ 239 | iSCSI Driver | SA | 240 +---------------------------+-------| 241 | | 242 | +--------+ +--------+ +---------+ | 243 | | iSCSI | | iSCSI | | iSCSI | | 244 | | target | | target | | target | | 245 | | "one" | | "two" | | "iscsi" | | 246 | +--------+ +--------+ +---------+ | 247 | | 248 | iSCSI Server | 249 +-----------------------------------+ 251 In the above drawing, the iSCSI server has three iSCSI targets that 252 the client could discover. The first two, targets "one" and "two", 253 are actual targets that can support SCSI commands. The third, 254 "iscsi", is the canonical target. An initiator can log in to the 255 canonical target, and use an iSCSI command called "SendTargets" to 256 obtain a list of the other targets within this iSCSI server. 258 Each of the iSCSI targets has a unique name, called an iSCSI Node 259 Name, or simply iSCSI Name. This identifier is the same regardless 260 of the network path (through adapter cards, networks, interfaces on 261 the storage device) over which the target is discovered and accessed. 262 For this example, the iSCSI names "one" and "two" are used. A real 263 iSCSI name incorporates more structure, including a naming authority, 264 and is not described here. 266 Each of the iSCSI targets in the drawing can appear at two addresses, 267 since two network interfaces are present. Each target, then, would 268 have two URLs. 270 An iSCSI target URL consists of its fully qualified host name or IP 271 address, the TCP port on which it is listening, and its world- wide 272 unique identifier. If the server in this drawing is listening at TCP 273 port 3000 for both network addresses, the service URLs present would 274 be: 276 - 10.1.30.21:3000/one 278 - 10.1.30.21:3000/two 280 - 10.1.30.21:3000/iscsi 282 - 10.1.40.3:3000/one 284 - 10.1.40.3:3000/two 286 - 10.1.40.3:3000/iscsi 288 An iSCSI server has two options when registering targets with the 289 service location protocol: 291 - Register the canonical target "iscsi" at each of its network 292 addresses. The initiator can use this target to discover the 293 others. This would create two service URLs in the example. 295 - The server can register the individual targets, "one" and "two", at 296 each of its network addresses. This would create four service URLs 297 in the example. 299 Although a target could do both types of registration, it would 300 probably not be helpful. 302 The iSCSI server constructs a service advertisement of the type 303 "service:iscsi:target" for each of the service URLs it wishes to 304 register. The advertisement contains a lifetime, along with other 305 attributes which are defined in the service template. 307 The remainder of the discovery procedure is identical to that used by 308 any client/server pair implementing SLP: 310 1. If an SLP DA is found, the SA contacts the DA and registers 311 the advertisement. If no DA is found, the SA maintains the 312 advertisement itself, answering multicast UA queries 313 directly. 315 2. When the iSCSI initiator requires contact information for an 316 iSCSI target, the UA either contacts the DA using unicast or 317 the SA using multicast. The UA includes a query based on 318 the attributes to indicate the characteristics of the 319 target(s) it requires. 321 3. Once the UA has the host name or address of the iSCSI server 322 as well as the port number and iSCSI Target Name, it can begin the 323 normal iSCSI login to the target. 325 5.2. Discovering Storage Name Services using SLP 327 Storage Name Servers can be built to perform discovery of targets in 328 a variety of ways. They can also provide extended services beyond 329 discovery, which could include storage allocation and management. 330 None of these services are defined here; the intent of this document 331 is to allow these services to be discovered by clients. 333 The following drawing shows an iSCSI client, an iSCSI server, and a 334 storage name server. To simplify the drawing, the second IP network 335 is not shown, but is assumed to exist. The storage name server would 336 use its own protocol (snsp) to provide capabilities to iSCSI clients 337 and servers; these clients and servers could both use SLP to discover 338 the storage name server. 340 +---------------------------+ 341 | iSCSI Client | 342 | | 343 | +-----------+ | 344 | | iSCSI | | 345 | | initiator | | 346 | +-----------+ | 347 | | 348 +---------------+------+----+ +------------+ 349 | iSCSI Driver | snsp | UA | | SLP DA | 350 +---------------+------+----+ | | 351 | TCP/UDP/IP | | (optional) | 352 +---------------+------+----+ +------------+ 353 | | 354 | IP Network | 355 ------------------------------------------ 356 | | 357 | | 358 +---------------+-----------+ +---------------------+ 359 | TCP/UDP/IP | | TCP/UDP/IP | 360 +---------------+------+----+ +---------------------+ 361 | iSCSI Driver | snsp | UA | | SA | snsp | 362 +---------------+------+----+ +---------------------+ 363 | | | | 364 | +--------+ +--------+ | | storage name server | 365 | | iSCSI | | iSCSI | | | | 366 | | target | | target | | +---------------------+ 367 | | 1 | | 2 | | 368 | +--------+ +--------+ | 369 | | 370 | iSCSI Server | 371 +---------------------------+ 373 Note the difference between the storage name server model and the 374 previously-defined target discovery model. When target discovery was 375 used, the iSCSI Server implemented an SA, to be discovered by the 376 initiator's UA. In the storage name server model, the iSCSI clients 377 and servers both implement UAs, and the name server implements the 378 SA. To be discovered by an initiator in this model, a target first 379 find the storage name server, and then register itself with the name 380 server using the name server's protocol. 382 A storage name server's URL contains the domain name or IP address 383 and TCP port. No other information is required. 385 The iSCSI server constructs a service advertisement of the type 386 "service:iscsi:target" for each of the addresses at which it appears. 387 The advertisement contains the URL, a lifetime, along with other 388 attributes which are defined in the service template. 390 The remainder of the discovery procedure is identical to that used to 391 discover iSCSI targets, except that both initiators and targets would 392 normally be "clients" of the storage name service. 394 5.3. Supporting Discovery of Targets and Name Services 396 An initiator should support, at a minimum, discovery of targets using 397 SLP. If an initiator also supports a storage name service, the 398 initiator should use SLP to discover the storage name service, and 399 perform target discovery through the name service. An initiator may 400 discover other targets directly even when using a name service, or 401 may discover targets via multiple name services. 403 For example, the name service may be used to discover targets at a 404 remote location, and SLP may used to discover local targets that are 405 not part of the service. 407 Targets that support a particular storage name service can be 408 configured to be discovered through that name service. A target 409 configured in this way should not answer direct SLP discovery 410 requests from initiators; they should effectively disable their 411 service:iscsi:target SA functionality while under the control of a 412 name service. This prevents targets from being duplicated between 413 SLP and the name service. A target should also not be configured to 414 support more than one name service at the same time. 416 5.4. Interoperating Between Initiators, Targets, and Name Services 418 Many initiators will support the basic discovery of targets using 419 SLP, but will not always support a particular storage name service in 420 use. A storage name server may provide the capability to support 421 these initiators by forming service advertisements for use through 422 its SA on behalf of the targets it has discovered. This would allow 423 an initiator to discover targets in a storage name service 424 environment, without having direct support for the storage name 425 service protocol in use. 427 Targets not supporting the storage name service protocol in use can 428 be discovered separately from the name service. 430 6. iSCSI SLP Templates 432 Three templates are provided: an iSCSI target template, a name 433 service template, and an abstract template to encapsulate the two. 435 6.1. The iSCSI Abstract Service Type Template 437 This template defines the abstract service "service:iscsi". It is 438 used as a top-level service to encapsulate all other iSCSI-related 439 services. 441 Name of submitter: Mark Bakke 442 Language of service template: en 443 Security Considerations: 444 See the security considerations of the concrete service types. 446 Template Text: 447 -------------------------template begins here----------------------- 448 template-type=iscsi 450 template-version=0.1 452 template-description= 453 This is an abstract service type. The purpose of the iscsi 454 service type is to encompass all of the services used to support 455 the iSCSI protocol. 457 template-url-syntax= 458 url-path= ; Depends on the concrete service type. 460 --------------------------template ends here------------------------ 462 6.2. The iSCSI Target Concrete Service Type Template 464 This template defines the service "service:iscsi:target". An entity 465 containing iSCSI targets that wishes them discovered via SLP would 466 register each of them, with each of their addresses, as this service 467 type. 469 Initiators and name services wishing to discover targets in this way 470 will generally use one of the following query strings: 472 1. Find a specific target, given its iSCSI Target Name: 474 Service: service:iscsi:target 475 Scope: initiator-or-name-server-scope-list 476 Query: (iscsi-name=fqn.com.acme.sn.456) 478 2. Find all of the iSCSI Target Names that may allow access to a 479 given 480 initiator: 482 Service: service:iscsi:target 483 Scope: initiator-or-name-server-scope-list 484 Query: (access-list=fqn.com.os.hostid.045A7B) 486 3. In addition, a name service may wish to discover all targets, 487 and assume responsibility for them. It may issue a simple query 488 for all of the targets: 490 Service: service:iscsi:target 491 Scope: name-server-scope-list 492 Query: none 494 4. Find the iSCSI Target Names from which the given initiator is 495 allowed 496 to boot: 498 Service: service:iscsi:target 499 Scope: name-server-scope-list 500 Query: (boot-list=fqn.com.os.hostid.045A7B) 502 More details on booting from an iSCSI target are defined in [BOOT]. 504 Name of submitter: Mark Bakke 505 Language of service template: en 506 Security Considerations: 507 See later section. 509 Template Text: 511 -------------------------template begins here----------------------- 512 template-type=iscsi:target 514 template-version=0.1 516 template-description= 517 This is concrete service type. The iscsi:target service type is used 518 to register individual target addresses to be discovered by others. 519 UAs will generally search for these by including one of the following: 520 - the iSCSI target name 521 - the iSCSI initiator name (must be in the access-list of the target) 522 - the service URL 524 template-url-syntax= 525 url-path = ipaddr [ : tcpport ] / iscsi-name 526 ipaddr = DNS host name or ip address 527 tcpport = decimal tcp port number 528 iscsi-name = iSCSI target name 529 ; The iscsi-name part of the URL is required and may be either the iSCSI 530 ; name of the target being registered, or the canonical name "iscsi". If an 531 ; initiator discovers a canonical iSCSI name, it should log in to that 532 ; target, and issue the iSCSI SendTargets command to discover additional 533 ; targets. A device representing multiple targets may then either 534 ; register each of them with SLP, or just register a single "iscsi" 535 ; target, which will be used to discover the remainder of the 536 ; targets. 537 ; 538 ; Examples: 539 ; service:iscsi:target://10.1.3.40:4000/fqn.com.acme.sn.45678 540 ; service:iscsi:target://mystorage.mycompany.com/iscsi 542 iscsi-name = string 543 # The iSCSI Name of this target. 544 # This must match the iscsi-name in the url-path. 546 transports = string M L 547 tcp 548 # This is a list of transport protocols that the registered 549 # entity supports. iSCSI is currently supported over TCP, 550 # but it is anticipated that it could be supported over other 551 # transports, such as SCTP, in the future. 552 tcp 554 entity = string O 555 # Normally the FQDN of the management interface of the entity 556 # containing this target. 558 mgmt-ipaddr = string O 559 # The IP address of the management interface appropriate for SNMP, 560 # web-based, or telnet management of the entity containing this 561 # target. 563 alias = string O 564 # The alias string contains a descriptive name of the target. 566 access-list = string M 567 # A list of iSCSI Initiator Names that can access this target. 568 # Normal iSCSI names will be 50 characters or less; max length is 255. 569 # Normally, only one or a few values will be in the list. 570 # Using the equivalence search on this will evaluate to "true" 571 # if any one of the items in this list matches the query. 572 # If this list contains the canonical name "iscsi", any initiator 573 # is allowed to access this target. 575 boot-list = string M O 576 # A list of iSCSI Initiator Names that can boot from this target. 577 # This list works precisely like the access-list attribute. A name appearing 578 # in this list must either appear in the access-list, or the 579 # access-list must contain the initiator name "iscsi". Otherwise, an 580 # initiator will be unable to find its boot target. 581 # If boot-list contains the name "iscsi", any host can boot from it, 582 # but I am not sure if this is useful to anyone. 583 # If this attribute is not registered, this target is not "bootable". 584 # 585 # Note that the LUN the host boots from is not specified here; a 586 # host will generally attempt to boot from LUN 0. 587 # 588 # It is quite possible that other attributes will need to be defined 589 # here for booting as well. 591 --------------------------template ends here------------------------ 593 6.3. iSCSI Name Service Templates 595 This template defines the service "service:iscsi:name-service". An 596 entity supporting one or more iSCSI name service protocols may 597 register itself with SLP as this service type. 599 Initiators wishing to discover name services using SLP will usually 600 search for them by the protocol(s) they support: 602 Service: service:iscsi:name-service 603 Scope: initiator-scope-list 604 Query: (protocols=isns) 606 Name of submitter: Mark Bakke 607 Language of service template: en 608 Security Considerations: 609 See later section. 611 Template Text: 612 -------------------------template begins here----------------------- 613 template-type=iscsi:name-service 615 template-version=0.1 617 template-description= 618 This is a concrete service type. The iscsi:name-service service type 619 provides the capability for entities supporting iSCSI to discover 620 appropriate name services. 622 template-url-syntax= 623 url-path = The URL of the name service. Defined in RFC 2608. 625 protocols = string M L 626 # The list of protocols supported by this name service. This 627 # list may be expanded in the future. There is no default. 628 # 629 # "isns" - The name service supports the use of the iSNS protocol 630 # to locate and register targets, and provide further 631 # information on them. This protocol is defined in [ISNS]. 632 isns 634 --------------------------template ends here------------------------ 636 7. Security Considerations 638 Service type templates provide information that is used to interpret 639 information obtained by clients through SLP. If the iSCSI templates 640 are modified or if false templates are distributed, iSCSI targets and 641 name servers may not correctly register themselves, or iSCSI clients 642 may not be able to interpret service information. 644 SLP provides an authentication mechanism for UAs to assure that 645 service advertisments only come from trusted SAs. [RFC2608] If trust 646 is an issue, particularly with respect to the information sought by 647 the client about IPSEC and IKE support, then SLP authentication 648 should be enabled in the network. 650 Once a target or name server is discovered, authentication and 651 authorization are handled by the iSCSI protocol, or by the name 652 server's protocol. It is the responsibility of the providers of 653 these services to ensure that an inappropriately advertised or 654 discovered service does not compromise their security. 656 8. Summary 658 This document describes how SLP can be used by iSCSI initiators to 659 find iSCSI targets and name servers. Service type templates for 660 iSCSI targets and name servers are presented. 662 9. References 664 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. Service 665 Location Protocol, version 2 RFC 2608, July, 1999. 667 [RFC2609] E. Guttman, C. Perkins, J. Kempf. Service Templates and 668 service: Schemes RFC 2609, July, 1999. 670 [RFC2119] S. Bradner. Key Words for Use in RFCs to Indicate 671 Requirement Levels. RFC 2119, March 1997. 673 [ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-04.txt, 674 February 2001. 676 [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. 678 [NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery 679 Requirements", draft-ietf-ips-iscsi-name-disc-01, April 680 2001. 682 [ISNS] J. Tseng, et. al. "Internet Storage Name Service", 683 draft-ietf-ips-isns-00, January 2001. 685 [BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for 686 Bootstrapping Clients using the iSCSI Protocol", 687 draft-ietf-ips-iscsi-boot-02, February 2001. 689 [RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with 690 SLP", draft-ietf-nat-rsip-slp-00, February 2000. 692 Author's Address: 694 Mark Bakke 695 Cisco Systems, Inc. 696 6450 Wedgwood Road 697 Maple Grove, MN 698 USA 55311 700 Voice: +1 763-398-1000 701 E-Mail: mbakke@cisco.com 703 Full Copyright Statement 705 Copyright (C) The Internet Society (2001). All Rights Reserved. 707 This document and translations of it may be copied and furnished to 708 others, and derivative works that comment on or otherwise explain it 709 or assist in its implementation may be prepared, copied, published 710 and distributed, in whole or in part, without restriction of any 711 kind, provided that the above copyright notice and this paragraph are 712 included on all such copies and derivative works. However, this 713 document itself may not be modified in any way, such as by removing 714 the copyright notice or references to the Internet Society or other 715 Internet organizations, except as needed for the purpose of 716 developing Internet standards in which case the procedures for 717 copyrights defined in the Internet Standards process must be 718 followed, or as required to translate it into languages other than 719 English. 721 The limited permissions granted above are perpetual and will not be 722 revoked by the Internet Society or its successors or assigns. 724 This document and the information contained herein is provided on an 725 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 726 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 727 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 728 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 729 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 731 Acknowledgement 733 Funding for the RFC Editor function is currently provided by the 734 Internet Society.