summaryrefslogtreecommitdiff
path: root/utils/open-isns/doc/rfc4018.txt
diff options
context:
space:
mode:
Diffstat (limited to 'utils/open-isns/doc/rfc4018.txt')
-rw-r--r--utils/open-isns/doc/rfc4018.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/utils/open-isns/doc/rfc4018.txt b/utils/open-isns/doc/rfc4018.txt
new file mode 100644
index 0000000..15df58d
--- /dev/null
+++ b/utils/open-isns/doc/rfc4018.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group M. Bakke
+Request for Comments: 4018 Cisco
+Category: Standards Track J. Hufferd
+ K. Voruganti
+ IBM
+ M. Krueger
+ HP
+ T. Sperry
+ Adaptec
+ April 2005
+
+
+ Finding Internet Small Computer Systems Interface (iSCSI) Targets
+ and Name Servers by Using Service Location Protocol version 2 (SLPv2)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ The iSCSI protocol provides a way for hosts to access SCSI devices
+ over an IP network. This document defines the use of the Service
+ Location Protocol (SLP) by iSCSI hosts, devices, and management
+ services, along with the SLP service type templates that describe the
+ services they provide.
+
+Table of Contents
+
+ 1. Introduction................................................ 2
+ 2. Notation Conventions........................................ 2
+ 3. Terminology................................................. 3
+ 4. Using SLP for iSCSI Service Discovery....................... 4
+ 5. iSCSI SLP Templates......................................... 11
+ 6. Security Considerations..................................... 18
+ 7. IANA Considerations......................................... 19
+ 8. Summary..................................................... 19
+ 9. Normative References........................................ 19
+ 10. Informative References...................................... 20
+ 11. Acknowledgements............................................ 21
+
+
+
+Bakke & Hufferd Standards Track [Page 1]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+1. Introduction
+
+ iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands,
+ data, and status across an IP network. This protocol is connection-
+ oriented and is currently defined over TCP. iSCSI uses a client-
+ server relationship. The client end of the connection is an
+ initiator, and it sends SCSI commands; the server end of the
+ connection is called a target, and it receives and executes the
+ commands.
+
+ There are several methods an iSCSI initiator can use to find the
+ targets to which it should connect. Two of these methods can be
+ accomplished without the use of SLP:
+
+ - Each target and its address can be statically configured on the
+ initiator.
+
+ - Each address providing targets can be configured on the initiator;
+ iSCSI provides a mechanism by which the initiator can query the
+ address for a list of targets.
+
+ The above methods are further defined in "iSCSI Naming and Discovery
+ Requirements" [RFC3721].
+
+ Each of the above methods requires a small amount of configuration to
+ be done on each initiator. The ability to discover targets and name
+ services without having to configure initiators is a desirable
+ feature. The Service Location Protocol (SLP) [RFC2608] is an IETF
+ standards track protocol providing several features that will
+ simplify locating iSCSI services. This document describes how SLP
+ can be used in iSCSI environments to discover targets, addresses
+ providing targets, and storage management servers.
+
+2. Notation Conventions
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 2]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+3. Terminology
+
+ Here are some definitions that may aid readers who are unfamiliar
+ with SLP, SCSI, or iSCSI. Some of these definitions have been
+ reproduced from [RFC2608] and "Finding an RSIP Server with SLP"
+ [RFC3105].
+
+ User Agent (UA) A process working on the client's behalf
+ to establish contact with some service.
+ The UA retrieves service information from
+ the Service Agents or Directory Agents.
+
+ Service Agent (SA) A process working on behalf of one or more
+ services to advertise the services and
+ their capabilities.
+
+ Directory Agent (DA) A process that collects service
+ advertisements. There can only be one DA
+ present per given host.
+
+ Scope A named set of services, typically making
+ up a logical administrative group.
+
+ Service Advertisement A URL, attributes, and a lifetime
+ (indicating how long the advertisement is
+ valid) providing service access
+ information and capabilities description
+ for a particular service.
+
+ Initiator A logical entity, typically within a host,
+ that sends SCSI commands to targets to be
+ executed. An initiator is usually present
+ in the form of a device driver.
+
+ Target A logical entity, typically within a
+ storage controller or gateway that
+ receives SCSI commands from an initiator
+ and executes them. A target includes one
+ or more Logical Units (LUs); each LU is a
+ SCSI device, such as a disk or tape drive.
+
+ iSCSI Name A UTF-8 character string that serves as a
+ unique identifier for iSCSI initiators and
+ targets. Its format and usage is further
+ defined in [RFC3721].
+
+ iSCSI Client A logical entity, typically a host that
+ includes at least one iSCSI Initiator.
+
+
+
+Bakke & Hufferd Standards Track [Page 3]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ iSCSI Server A logical entity, typically a storage
+ controller or gateway that includes at
+ least one iSCSI Target.
+
+ Storage Management Server An addressable entity that provides
+ management services that benefit an iSCSI
+ environment. "Storage management server"
+ is used as a generic term and does not
+ indicate a specific protocol or service.
+
+4. Using SLP for iSCSI Service Discovery
+
+ Two entities are involved in iSCSI discovery. The end result is that
+ an iSCSI initiator (e.g., a host) discovers iSCSI targets, usually
+ provided by storage controllers or gateways.
+
+ iSCSI targets are registered with SLP as a set of service URLs, one
+ for each address on which the target may be accessed. Initiators
+ discover these targets by using SLP service requests. Targets that
+ do not directly support SLP or that are under the control of a
+ management service may be registered by a proxy service agent as part
+ of the software providing this service.
+
+ iSCSI entities may also use SLP to discover higher-level management
+ services when these are needed.
+
+ This section first describes the use of SLP for discovery of targets
+ by iSCSI initiators, it then describes the use of SLP to discover
+ storage management servers.
+
+ This document assumes that SLPv2 will be used for discovering iSCSI-
+ related services; no attempt is made to include support for SLPv1.
+
+4.1. Discovering iSCSI Targets with SLP
+
+ The following diagram shows the relationship among iSCSI clients,
+ servers, initiators, and targets. An iSCSI client includes at least
+ one iSCSI initiator, and an SLP user agent (UA). An iSCSI server
+ includes at least one iSCSI target an SLP service agent (SA). Some
+ entities, such as extended copy engines, include both initiators and
+ targets. These include both an SA, for its targets to be discovered,
+ and a UA, for its initiator(s) to discover other targets.
+
+
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 4]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ +---------------------------------+
+ | iSCSI Client |
+ | +-----------+ |
+ | | iSCSI | |
+ | | initiator | |
+ | | "myhost" | |
+ | +-----------+ |
+ | |
+ +--------------------------+------+
+ | iSCSI Driver | UA |
+ +--------------------------+------+
+ | TCP/UDP/IP |
+ +----------------+----------------+
+ | Interface 1 | Interface 2 |
+ +----------------+----------------+
+ | |
+ +------------+ | | +------------+
+ | SLP DA | | | | SLP DA |
+ | (optional) |----+ IP Networks +----| (optional) |
+ +------------+ | | +------------+
+ | |
+ +-----------------+-----------------|
+ | Interface 1 | Interface 2 |
+ | 192.0.2.131 | 192.0.2.3 |
+ +-----------------+-----------------+
+ | TCP/UDP/IP |
+ +---------------------------+-------+
+ | iSCSI Driver | SA |
+ +---------------------------+-------|
+ | |
+ | +--------+ +--------+ +---------+ |
+ | | iSCSI | | iSCSI | | iSCSI | |
+ | | target | | target | | target | |
+ | | "one" | | "two" | | "three" | |
+ | +--------+ +--------+ +---------+ |
+ | iSCSI Server |
+ +-----------------------------------+
+
+ In the above drawing, the iSCSI server has three iSCSI targets that
+ the client could discover, named "one", "two" and "three". The iSCSI
+ client has an iSCSI initiator with the name "myhost". The iSCSI
+ client may use the initiator name in its SLP Service Requests as a
+ filter to discover only targets that are configured to accept iSCSI
+ connections from "myhost".
+
+ Each iSCSI target and initiator has a unique name, called an iSCSI
+ Name. This identifier is the same regardless of the network path
+ (through adapter cards, networks, and interfaces on the storage
+
+
+
+Bakke & Hufferd Standards Track [Page 5]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ device) over which the target is discovered and accessed. For this
+ example, the iSCSI names "one", "two", and "three" are used for the
+ targets; the initiator uses the name "myhost". An actual iSCSI name
+ would incorporate more structure, including a naming authority, and
+ is not described here.
+
+ Each of the iSCSI targets in the drawing can appear at two addresses,
+ since two network interfaces are present. Each target would have two
+ service URLs, unless a single service URL included a DNS host name
+ mapping to both addresses.
+
+ An iSCSI target URL consists of its fully qualified host name or IP
+ address, the TCP port on which it is listening, and its iSCSI name.
+ An iSCSI server must register each of its individual targets at each
+ of its network addresses.
+
+ The iSCSI server constructs a service advertisement of the type
+ "service:iscsi:target" for each of the service URLs it wishes to
+ register. The advertisement contains a lifetime, along with other
+ attributes that are defined in the service template.
+
+ If the server in the above drawing is listening at TCP port 3260 for
+ both network addresses, the service URLs registered would be
+
+ - 192.0.2.131:3260/one
+
+ - 192.0.2.131:3260/two
+
+ - 192.0.2.131:3260/three
+
+ - 192.0.2.3:3260/one
+
+ - 192.0.2.3:3260/two
+
+ - 192.0.2.3:3260/three
+
+ The remainder of the discovery procedure is identical to that used by
+ any client/server pair implementing SLP:
+
+ 1. If an SLP DA is found, the SA contacts the DA and registers the
+ service advertisement. Whether or not one or more SLPv2 DAs are
+ discovered, the SA maintains the advertisement itself and answers
+ multicast UA queries directly.
+
+ 2. When the iSCSI initiator requires contact information for an
+ iSCSI target, the UA either contacts the DA by using unicast or
+ the SA by using multicast. If a UA is configured with the
+ address of the SA, it may avoid multicast and may contact an SA
+
+
+
+Bakke & Hufferd Standards Track [Page 6]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ by using unicast. The UA includes a query based on the
+ attributes to indicate the characteristics of the target(s) it
+ requires.
+
+ 3. Once the UA has the host name or address of the iSCSI server, as
+ well as the port number and iSCSI Target Name, it can begin the
+ normal iSCSI login to the target.
+
+ As information contained in the iSCSI target template may exceed
+ common network datagram sizes, the SLP implementation for both UAs
+ and SAs supporting this template MUST implement SLP over TCP.
+
+4.1.1. Finding Targets Based on Initiator Credentials
+
+ To be allowed access to an iSCSI target, an initiator must be
+ authenticated. The initiator may be required by the target to
+ produce one or more of the following credentials:
+
+ - An iSCSI Initiator Name
+
+ - An IP address
+
+ - A CHAP, SRP, or Kerberos credential
+
+ - Any combination of the above
+
+ Most iSCSI targets allow access to only one or two initiators. In
+ the ideal discovery scenario, an initiator would send an SLP request
+ and receive responses ONLY for targets to which the initiator is
+ guaranteed a successful login. To achieve this goal, the iSCSI
+ target template contains the following attributes, each of which
+ allows a list of values:
+
+ 1. auth-name: This attribute contains the list of initiator names
+ allowed to access this target, or the value "any", indicating
+ that no specific initiator name is required.
+
+ 2. auth-addr: This attribute contains the list of host names
+ and/or IP addresses that will be allowed access to this target,
+ or the value "any", indicating that no specific address or
+ host name is required. If a large number of addresses is to
+ be allowed (perhaps a subnet), this attribute may contain the
+ value "any".
+
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 7]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ 3. auth-cred: This attribute contains a list of "method/identifier"
+ credentials that will be allowed access to the target, provided
+ they can produce the correct password or other verifier during
+ the login process. If no specific credentials are required, the
+ value "any" is used.
+
+ The list of valid method strings for auth-cred are defined in
+ [RFC3720], section 11.1, "AuthMethod". The identifier used after the
+ "/" is defined by the specific AuthMethod, also in [RFC3720].
+ Examples showing initiator searches based on auth-xxxx attributes are
+ shown in the target-specific template section below.
+
+ Also note that the auth-xxxx attributes are considered security
+ policy information. If these attributes are distributed, IPsec MUST
+ be implemented as specified in the Security Implementation section
+ below.
+
+4.1.2. Supporting Access by Multiple Identities to the Same Target
+
+ If a target is to allow access to multiple host identities, more than
+ one combination of auth-xxxx attributes will have to be allowed. In
+ some of these cases, it is not possible to express the entire set of
+ valid combinations of auth-xxxx attributes within a single registered
+ service URL. For example, if a target can be addressed by
+
+ auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)
+
+ OR
+
+ auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)
+
+ the above cannot be specified in a single registered service URL,
+ since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1,
+ auth-cred=CHAP/user2) would allow either auth-name to be used with
+ either auth-cred. This necessitates the ability to register a target
+ and address under more than one service URL; one for (identity1) and
+ one for (identity2).
+
+ Because service URLs must be unique, (identity1) and (identity2) must
+ each be registered under a unique service URL. For systems that
+ support the configuration of multiple identities to access a target,
+ the service URL must contain an additional, opaque string defining
+ the identity. This appears after the iSCSI name in the URL string
+ and is separated by a "/". Each registered (target-address, target-
+ name, initiator-identity) tuple can then register a set of auth-xxxx
+ attributes.
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 8]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+4.1.3. Using SLP in a Non-multicast Environment
+
+ In some networks, the use of multicast for discovery purposes is
+ either unavailable or not allowed. These include public or service-
+ provider networks that are placed between an iSCSI client and a
+ server. These are probably most common between two iSCSI gateways,
+ one at a storage service provider site, and one at a customer site.
+
+ In these networks, an initiator may allow the addresses of one or
+ more SAs to be configured instead of or in addition to its DA
+ configuration. The initiator would then make unicast SLP service
+ requests directly to these SAs, without the use of multicast to
+ discover them first.
+
+ This functionality is well within the scope of the current SLP
+ protocol. The main consequence for implementors is that an initiator
+ configured to make direct unicast requests to an SA will have to add
+ this to the SLP API, if it is following the service location API
+ defined in [RFC2614].
+
+4.2. Discovering Storage Management Services with SLP
+
+ Storage management servers can be built to manage and control access
+ to targets in a variety of ways. They can provide extended services
+ beyond discovery, which could include storage allocation and
+ management. None of these services are defined here; the intent of
+ this document is to allow these services to be discovered by both
+ clients and servers, in addition to the target discovery already
+ being performed.
+
+ The following drawing shows an iSCSI client, an iSCSI server, and a
+ storage management server. To simplify the drawing, the second IP
+ network is not shown but is assumed to exist. The storage management
+ server would use its own protocol (smsp) to provide capabilities to
+ iSCSI clients and servers; these clients and servers can both use SLP
+ to discover the storage management server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 9]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ +---------------------------+
+ | iSCSI Client |
+ | |
+ | +-----------+ |
+ | | iSCSI | |
+ | | initiator | |
+ | +-----------+ |
+ | |
+ +---------------+------+----+ +------------+
+ | iSCSI Driver | smsp | UA | | SLP DA |
+ +---------------+------+----+ | |
+ | TCP/UDP/IP | | (optional) |
+ +---------------+------+----+ +------------+
+ | |
+ | IP Network |
+ ------------------------------------------
+ | |
+ | |
+ +---------------+-----------+ +---------------------+
+ | TCP/UDP/IP | | TCP/UDP/IP |
+ +---------------+------+----+ +---------------------+
+ | iSCSI Driver | smsp | UA | | SA | smsp |
+ +---------------+------+----+ +---------------------+
+ | | | |
+ | +--------+ +--------+ | | storage mgmt server |
+ | | iSCSI | | iSCSI | | | |
+ | | target | | target | | +---------------------+
+ | | 1 | | 2 | |
+ | +--------+ +--------+ |
+ | |
+ | iSCSI Server |
+ +---------------------------+
+
+ Note the difference between the storage management server model and
+ the previously defined target discovery model. When target discovery
+ was used, the iSCSI Server implemented an SA, to be discovered by the
+ initiator's UA. In the storage management server model, the iSCSI
+ clients and servers both implement UAs, and the management server
+ implements the SA.
+
+ A storage management server's URL contains the domain name or IP
+ address and TCP or UDP port number. No other information is
+ required.
+
+ The storage management server constructs a service advertisement of
+ the type "service:iscsi:sms" for each of the addresses at which it
+ appears. The advertisement contains the URL and a lifetime, along
+ with other attributes that are defined in the service template.
+
+
+
+Bakke & Hufferd Standards Track [Page 10]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ The remainder of the discovery procedure is identical to that used to
+ discover iSCSI targets, except that both initiators and targets would
+ normally be "clients" of the storage management service.
+
+ Targets that support a storage management service implement a UA in
+ addition to the SA. A target may alternatively just implement the UA
+ and allow the storage management service to advertise its targets
+ appropriately by providing an SA and registering the appropriate
+ service:iscsi:target registrations on the target's behalf: The target
+ device would not have to advertise its own targets. This has no
+ impact on the initiator.
+
+ This allows the initiators' discovery of targets to be completely
+ interoperable regardless of which storage management service is used,
+ or whether one is used at all, or whether the target registrations
+ are provided directly by the target or by the management service.
+
+4.3. Internationalization Considerations
+
+ SLP allows internationalized strings to be registered and retrieved.
+ Attributes in the template that are not marked with an 'L' (literal)
+ will be registered in a localized manner. An "en" (English)
+ localization MUST be registered, and others MAY be registered.
+
+ Attributes that include non-ASCII characters will be encoded by using
+ UTF-8, as discussed in [RFC3722] and [RFC3491].
+
+5. iSCSI SLP Templates
+
+ Three templates are provided: an iSCSI target template, a management
+ service template, and an abstract template to encapsulate the two.
+
+5.1. The iSCSI Abstract Service Type Template
+
+ This template defines the abstract service "service:iscsi". It is
+ used as a top-level service to encapsulate all other iSCSI-related
+ services.
+
+ Name of submitter: Mark Bakke
+ Language of service template: en
+ Security Considerations: See section 6.
+
+ Template Text:
+ -------------------------template begins here-----------------------
+ template-type=iscsi
+ template-version=1.0
+
+ template-description=
+
+
+
+Bakke & Hufferd Standards Track [Page 11]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ This is an abstract service type. The purpose of the iscsi
+ service type is to encompass all of the services used to support
+ the iSCSI protocol.
+
+ template-url-syntax=
+ url-path= ; Depends on the concrete service type.
+
+ --------------------------template ends here------------------------
+
+5.2. The iSCSI Target Concrete Service Type Template
+
+ This template defines the service "service:iscsi:target". An entity
+ containing iSCSI targets that wishes them discovered via SLP would
+ register each of them, with each of their addresses, as this service
+ type.
+
+ Initiators (and perhaps management services) wishing to discover
+ targets in this way will generally use one of the following queries:
+
+ 1. Find a specific target, given its iSCSI Target Name:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: (iscsi-name=iqn.2001-04.com.example:sn.456)
+
+ 2. Find all of the iSCSI Target Names that may allow access to a
+ given initiator:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: (auth-name=iqn.1998-03.com.example:hostid.045A7B)
+
+ 3. Find all of the iSCSI Target Names that may allow access to
+ any initiator:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: (auth-name=any)
+
+ 4. Find all of the iSCSI Target Names that may allow access to
+ this initiator, or that will allow access to any initiator:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: &(auth-name=iqn.1998-03.com.example:hostid.045A7B)
+ (auth-name=any)
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 12]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ 5. Find all of the iSCSI Target Names that may allow access to
+ a given CHAP user name:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: (auth-cred=chap/my-user-name)
+
+ 6. Find all of the iSCSI Target Names that may allow access to a
+ given initiator that supports two IP addresses, a CHAP credential
+ and SRP credential, and an initiator name:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any)
+ |(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any)
+ |(auth-cred=chap/foo)(auth-cred=srp/my-user-name)
+ (auth-cred=any))
+
+ 7. Find the iSCSI Target Names from which the given initiator is
+ allowed to boot:
+
+ Service: service:iscsi:target
+ Scope: initiator-scope-list
+ Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B)
+
+ 8. In addition, a management service may wish to discover all
+ targets:
+
+ Service: service:iscsi:target
+ Scope: management-server-scope-list
+ Query: <empty-string>
+
+ More details on booting from an iSCSI target are defined in [BOOT].
+
+ Name of submitter: Mark Bakke
+ Language of service template: en
+ Security Considerations: see section 6.
+
+ Template Text:
+ -------------------------template begins here-----------------------
+ template-type=iscsi:target
+ template-version=1.0
+
+ template-description=
+
+ This is a concrete service type. The iscsi:target service type is
+ used to register individual target addresses to be discovered
+ by others. UAs will generally search for these by including one of
+
+
+
+Bakke & Hufferd Standards Track [Page 13]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ the following:
+
+ - the iSCSI target name
+ - iSCSI initiator identifiers (iSCSI name, credential, IP address)
+ - the service URL
+
+ template-url-syntax=
+ url-path = hostport "/" iscsi-name [ "/" identity ]
+ hostport = host [ ":" port ]
+ host = hostname / hostnumber ; DNS name or IP address
+ hostname = *( domainlabel "." ) toplabel
+ alphanum = ALPHA / DIGIT
+ domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
+ toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
+ hostnumber = ipv4-number / ipv6-addr ; IPv4 or IPv6 address
+ ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
+ ipv6-addr = "[" ipv6-number "]"
+ ipv6-number = 6( h16 ":" ) ls32
+ / "::" 5( h16 ":" ) ls32
+ / [ h16 ] "::" 4( h16 ":" ) ls32
+ / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
+ / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
+ / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
+ / [ *4( h16 ":" ) h16 ] "::" ls32
+ / [ *5( h16 ":" ) h16 ] "::" h16
+ / [ *6( h16 ":" ) h16 ] "::"
+ ls32 = ( h16 ":" h16 ) / ipv4-number
+ ; least-significant 32 bits of ipv6 address
+ h16 = 1*4HEXDIG
+ port = 1*DIGIT
+ iscsi-name = iscsi-char ; iSCSI target name
+ identity = iscsi-char ; optional identity string
+ iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "."
+ ; Intended to allow UTF-8 encoded strings
+ escaped = 1*("\" HEXDIG HEXDIG)
+ ;
+ ; The iscsi-name part of the URL is required and must be the iSCSI
+ ; name of the target being registered.
+ ; A device representing multiple targets must individually
+ ; register each target/address combination with SLP.
+ ; The identity part of the URL is optional, and is used to
+ ; indicate an identity that is allowed to access this target.
+ ;
+ ; Example (split into two lines for clarity):
+ ; service:iscsi:target://192.0.2.3:3260/
+ ; iqn.2001-04.com.example:sn.45678
+ ;
+ ; IPv6 addresses are also supported; they use the notation
+
+
+
+Bakke & Hufferd Standards Track [Page 14]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ ; specified above and in [RFC3513], section 2.2
+
+ iscsi-name = string
+ # The iSCSI Name of this target.
+ # This must match the iscsi-name in the url-path.
+
+ portal-group = integer
+ # The iSCSI portal group tag for this address. Addresses sharing
+ # the same iscsi-name and portal-group tag can be used within the
+ # same iSCSI session. Portal groups are described in [RFC3720].
+
+ transports = string M L
+ tcp
+ # This is a list of transport protocols that the registered
+ # entity supports. iSCSI is currently supported over TCP,
+ # but it is anticipated that it could be supported over other
+ # transports, such as SCTP, in the future.
+ tcp
+
+ mgmt-entity = string O
+ # The fully qualified domain name, or IP address in dotted-decimal
+ # notation, of the management interface of the entity containing
+ # this target.
+ #
+
+ alias = string O
+ # The alias string contains a descriptive name of the target.
+
+ auth-name = string M X
+ # A list of iSCSI Initiator Names that can access this target.
+ # Normal iSCSI names will be 80 characters or less; max length
+ # is 255.
+ # Normally, only one or a few values will be in the list.
+ # Using the equivalence search on this will evaluate to "true"
+ # if any one of the items in this list matches the query.
+ # If this list contains the default name "any", any initiator
+ # is allowed to access this target, provided it matches
+ # the other auth-xxx attributes.
+ #
+ # This attribute contains security policy information. If this
+ # attribute is distributed via an Attribute Reply message,
+ # IPsec MUST be implemented.
+
+ auth-addr = string M X
+ # A list of initiator IP addresses (or host names) which will
+ # be allowed access to this target. If this list contains the
+ # default name "any", any IP address is allowed access to this
+ # target, provided it matches the other auth-xxx attributes.
+
+
+
+Bakke & Hufferd Standards Track [Page 15]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ #
+ # This attribute contains security policy information. If this
+ # attribute is distributed via an Attribute Reply message,
+ # IPsec MUST be implemented.
+
+ auth-cred = string M X
+ # A list of credentials which will be allowed access to the target
+ # (provided they can provide the correct password or other
+ # authenticator). Entries in this list are of the form
+ # "method/identifier", where the currently defined methods are
+ # "chap" and "srp", both of which take usernames as their
+ # identifiers.
+ #
+ # This attribute contains security policy information. If this
+ # attribute is distributed via an Attribute Reply message,
+ # IPsec MUST be implemented.
+
+ boot-list = string M O
+ # A list of iSCSI Initiator Names that can boot from this target.
+ # This list works precisely like the auth-name attribute. A name
+ # appearing in this list must either appear in the access-list,
+ # or the access-list must contain the initiator name "iscsi".
+ # Otherwise, an initiator will be unable to find its boot
+ # target. If boot-list contains the name "iscsi", any host can boot
+ # from it, but I am not sure if this is useful to anyone. If this
+ # attribute is not registered, this target is not "bootable".
+ #
+ # Note that the LUN the host boots from is not specified here; a
+ # host will generally attempt to boot from LUN 0.
+ #
+ # It is quite possible that other attributes will need to be defined
+ # here for booting as well.
+ #
+ # This attribute contains security policy information. If this
+ # attribute is distributed via an Attribute Reply message,
+ # IPsec MUST be implemented.
+
+ --------------------------template ends here------------------------
+
+5.3. iSCSI Storage Management Service Templates
+
+ This template defines the service "service:iscsi:sms". An entity
+ supporting one or more iSCSI management service protocols may
+ register itself with SLP as this service type. iSCSI clients and
+ servers wishing to discover storage management services using SLP
+ will usually search for them by the protocol(s) they support:
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 16]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ Service: service:iscsi:sms
+ Scope: initiator-scope-list
+ Query: (protocols=isns)
+
+ Name of submitter: Mark Bakke
+ Language of service template: en
+ Security Considerations: see section 6.
+
+ Template Text:
+ -------------------------template begins here-----------------------
+ template-type=iscsi:sms
+ template-version=1.0
+
+ template-description=
+ This is a concrete service type. The iscsi:sms service type
+ provides the capability for entities supporting iSCSI to discover
+ appropriate management services.
+
+ template-url-syntax=
+ url-path = ; The URL of the management service [RFC2608].
+
+ protocols = string M
+ # The list of protocols supported by this name service. This
+ # list may be expanded in the future. There is no default.
+ #
+ # "isns" - This management service supports the use of the iSNS
+ # protocol for access management, health monitoring, and
+ # discovery management services. This protocol is defined
+ # in [ISNS].
+ isns
+
+ transports = string M L
+ tcp
+ # This is a list of transport protocols that the registered
+ # entity supports.
+ tcp, udp
+
+ server-priority = integer
+ # The priority a client should give this server, when choosing
+ # between multiple servers with the same protocol type.
+ # When multiple servers are discovered for a given protocol type,
+ # this parameter indicates their relative precedence. Server
+ # precedence is protocol-specific; for some protocols, the primary
+ # server may have the highest server-priority value, while for
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 17]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ # others it may have the lowest. For example, with iSNS, the primary
+ # server has the lowest value (value 0).
+
+ --------------------------template ends here------------------------
+
+6. Security Considerations
+
+ The SLPv2 security model as specified in [RFC2608] does not provide
+ confidentiality but does provide an authentication mechanism for UAs
+ to ensure that service advertisements only come from trusted SAs,
+ with the exception that it does not provide a mechanism to
+ authenticate "zero-result responses". See [RFC3723] for a discussion
+ of the SLPv2 [RFC2608] security model.
+
+ Once a target or management server is discovered, authentication and
+ authorization are handled by the iSCSI protocol, or by the management
+ server's protocol. It is the responsibility of the providers of
+ these services to ensure that an inappropriately advertised or
+ discovered service does not compromise their security.
+
+ When no security is used for SLPv2, there is a risk of distribution
+ of false discovery information. The primary countermeasure for this
+ risk is authentication. When this risk is a significant concern,
+ IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI
+ traffic subject to this risk to ensure that iSCSI traffic only flows
+ between endpoints that have participated in IKE authentication and
+ iSCSI in-band authentication. For example, if an attacker
+ distributes discovery information falsely claiming that it is an
+ iSCSI target, it will lack the secret information necessary to
+ complete IKE authentication or iSCSI in-band authentication
+ successfully and therefore will be prevented from falsely sending or
+ receiving iSCSI traffic.
+
+ A risk remains of a denial of service attack based on repeated use of
+ false discovery information that will cause initiation of IKE
+ negotiation. The countermeasures for this are administrative
+ configuration of each iSCSI Target to limit the peers it is willing
+ to communicate with (i.e., by IP address range and/or DNS domain),
+ and maintenance of a negative authentication cache to avoid
+ repeatedly contacting an iSCSI Target that fails to authenticate.
+ These three measures (i.e., IP address range limits, DNS domain
+ limits, negative authentication cache) MUST be implemented.
+
+ The auth-name, auth-addr, auth-cred, and boot-list attributes
+ comprise security policy information. When these are distributed,
+ IPsec MUST be implemented.
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 18]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+6.1. Security Implementation
+
+ Security for SLPv2 in an IP storage environment is specified in
+ [RFC3723]. IPsec is mandatory-to-implement for IPS clients and
+ servers. Thus, all IP storage clients, including those invoking SLP,
+ can be assumed to support IPsec. SLP servers, however, cannot be
+ assumed to implement IPsec, since there is no such requirement in
+ standard SLP. In particular, SLP Directory Agents (DA) may be
+ running on machines other than those running the IPS protocols.
+
+ IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this
+ includes ESP with a non-null transform to provide both authentication
+ and confidentiality.
+
+ When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred,
+ and boot-list information (see section 5.2 above), IPsec MUST be
+ implemented, as these items are considered sensitive security policy
+ information. If IPsec is not implemented, auth-name, auth-addr,
+ auth-cred, and boot-list information MUST NOT be distributed via
+ SLPv2 and MUST NOT be used if discovered via SLPv2.
+
+ Because the IP storage services have their own authentication
+ capabilities when located, SLPv2 authentication is OPTIONAL to
+ implement and use (as discussed in more detail in [RFC3723]).
+
+7. IANA Considerations
+
+ This document describes three SLP Templates. They have been reviewed
+ and approved by the IESG and registered in the IANA's "SVRLOC
+ Templates" registry. This process is described in the IANA
+ Considerations section of [RFC2609].
+
+8. Summary
+
+ This document describes how SLP can be used by iSCSI initiators to
+ find iSCSI targets and storage management servers. Service type
+ templates for iSCSI targets and storage management servers are
+ presented.
+
+9. Normative References
+
+ [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
+ "Service Location Protocol, Version 2", RFC 2608, June
+ 1999.
+
+ [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service
+ Templates and Service: Schemes", RFC 2609, June 1999.
+
+
+
+
+Bakke & Hufferd Standards Track [Page 19]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+ Profile for Internationalized Domain Names (IDN)", RFC
+ 3491, March 2003.
+
+ [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
+ (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+ [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
+ and E. Zeidner, "Internet Small Computer Systems
+ Interface (iSCSI)", RFC 3720, April 2004.
+
+ [RFC3722] Bakke, M., "String Profile for Internet Small Computer
+ Systems Interface (iSCSI) Names", RFC 3722, April 2004.
+
+ [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
+ Travostino, "Securing Block Storage Protocols over IP",
+ RFC 3723, April 2004.
+
+10. Informative References
+
+ [RFC2614] Kempf, J. and E. Guttman, "An API for Service Location",
+ RFC 2614, June 1999.
+
+ [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
+
+ [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
+ Krueger, "Internet Small Computer Systems Interface
+ (iSCSI) Naming and Discovery", RFC 3721, April 2004.
+
+ [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and
+ J. Souza, "Internet Storage Name Service", Work in
+ Progress, February 2004.
+
+ [BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard
+ for Bootstrapping Clients using the iSCSI Protocol", Work
+ in Progress, March 2004.
+
+ [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
+ SLP", RFC 3105, October 2001.
+
+
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 20]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+11. Acknowledgements
+
+ This document was produced by the iSCSI Naming and Discovery team,
+ including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti
+ (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad),
+ Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry
+ (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran
+ (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt
+ Peterson (Caldera) and James Kempf (Sun) for reviewing the document
+ from an SLP perspective.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 21]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+Authors' Addresses
+
+ Mark Bakke
+ Cisco Systems, Inc.
+ 7900 International Drive, Suite 400
+ Bloomington, MN
+ USA 55425
+
+ EMail: mbakke@cisco.com
+
+
+ Kaladhar Voruganti
+ IBM Almaden Research Center
+ 650 Harry Road
+ San Jose, CA 95120
+
+ EMail: kaladhar@us.ibm.com
+
+
+ John L. Hufferd
+ IBM Storage Systems Group
+ 5600 Cottle Road
+ San Jose, CA 95193
+
+ Phone: +1 408 997-6136
+ EMail: jlhufferd@comcast.net
+
+
+ Marjorie Krueger
+ Hewlett-Packard Corporation
+ 8000 Foothills Blvd
+ Roseville, CA 95747-5668, USA
+
+ Phone: +1 916 785-2656
+ EMail: marjorie_krueger@hp.com
+
+
+ Todd Sperry
+ Adaptec, Inc.
+ 691 South Milpitas Boulevard
+ Milpitas, Ca. 95035
+
+ Phone: +1 408 957-4980
+ EMail: todd_sperry@adaptec.com
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 22]
+
+RFC 4018 iSCSI and SLPv2 April 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Bakke & Hufferd Standards Track [Page 23]
+
View Lorry Controller Status