doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc4018.txt b/doc/rfc/rfc4018.txt
new file mode 100644
index 0000000..15df58d
--- /dev/null
+++ b/doc/rfc/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]
+