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)