[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3721

          Internet Draft
          Draft Title: iSCSI Naming and Discovery
                                                    Mark Bakke
                                                    Joe Czap
                                                    Jim Hafner
                                                    Howard Hall
                                                    Jack Harwood
                                                    John Hufferd
                                                    Yaron Klein
                                                    Lawrence Lamers
                                                    San Valley Systems
                                                    Todd Sperry
                                                    Joshua Tseng
                                                    Kaladhar Voruganti
    draft-ietf-ips-iscsi-name-disc-00.           February, 2001
            Expires August 2001
       iSCSI Naming and Discovery
            Status of this Memo
   Voruganti  iSCSI Naming and Discovery  February 2001               1
                    Using Microsoft Word to create       February 2001
                      Internet Drafts and RFC's
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 except that the right to
   produce derivative works is not granted. Internet-Drafts are working
   documents of the Internet Engineering.Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts. Internet-Drafts are draft
   documents valid for a maximum of six months and may be updated,
   replaced, or obsoleted by other documents at any time. It is
   inappropriate to use Internet- Drafts as reference material or to
   cite them other than as "work in progress." The list of current
   Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-
              iSCSI Naming and Discovery        February 2000
   The list of Internet-Draft Shadow Directories can be accessed at
   Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or
   to kaladhar@us.ibm.com
   1. Abstract
   This document describes both the  iSCSI [7] naming and discovery
   requirements, and the details of these mechanisms.
   The  requirements presented in this document have been
   agreed to by the members of  the iSCSI naming and discovery team.
   This document complements the iSCSI IETF  draft. Flexibility is the
   key guiding principle behind both the naming and discovery designs.
   That is, an effort has been made to satisfy the needs of both
   small  isolated environments, as well as large environments
   requiring secure/scalable solutions.
   This document has been organized into the following sections:
   a) Section 3 presents the naming requirements. It discusses the
   concept of a world wide unique identifer (WWUI).
   b) Section 4 discusses the discovery requirements.
   c) Section 5 presents Storage Name Server (SNS) requirements.
   d) Section 6 presents the details of iSNS protocol. iSNS
   meets the requirements of SNS. The protocols identified in section
   6, which are used by iSNS, MUST also be supported by any iSCSI
   compliant SNS protocol.
   e) Section 7 briefly lists some other discovery protocols.
   Voruganti iSCSI Naming and Discovery - Expires August 2001        2
   f) Section 8 briefly discusses the security implications on the
   discovery mechanism.
   g) Appendix A describes the different hardware and software
   components with whom the initiator and target WWUIs can be
   h) Appendix B contains examples on how the WWUIs are to be used in
   iSCSI Login commands.
   i) Appendix C contains a taxonomy of iSCSI proxy and firewall
   concepts. This taxonomy helps to evaluate the behavior of the
   discovery mechanism when dealing with proxies and firewalls.
   2. Conventions used in this document
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119.
   3. Naming Requirements
   In order for an iSCSI initiator to connect to an iSCSI target, the
   initiator  needs to provide information about the Network Entity
   object, Portal Object and  the target Storage Node object. The
   details of these three iSCSI objects are as  follows:
   a) Network Entity Object
   The Network Entity object represents a device or gateway that is
   accessible from  the IP network. This device or gateway may support
   one or more initiators or  targets that are either internal to the
   storage device or accessible through a  network behind the gateway.
   Each initiator or target is represented by subordinate Storage Node
   b) Portal Object
   The Portal object is a port through which access to any Storage Node
   object within the Network Entity object can be obtained. A Network
   Entity object  must have one or more Portal objects, each of which is
   usable by Storage Node  objects contained in that Network Entity
   object to gain access to the IP network. The Portal object is
   identified by its IP address and Port number.
   c) Storage Node Object
   The Storage Node object defines an individual iSCSI initiator or
   target. There may be one or more Storage Node objects within the
   Network Entity object. A Storage Node object is identified by its
   world wide unique identifier (WWUI). There is a requirement to have
   the ability to generate world wide unique identifiers (WWUIs) for
   both iSCSI initiators and targets. However, it is not mandatory for
   the initiators and targets to use WWUIs because a globally unique
   identifier might not be required in some simple, isolated iSCSI
   configurations. WWUIs are useful because in some cases (e.g. when
   Voruganti iSCSI Naming and Discovery - Expires August 2001        3
   DHCP services [6] are used etc), the combination of IP address and
   port number [6] cannot uniquely identify an initiator or a target.
   There is a default Storage Node object present at every target
   network entity that can be accessed without specifying the WWUI.
   However, if there are multiple iSCSI target Storage Nodes that are
   serviced by a single Network Entity and  Portal objects, then it is
   necessary for the initiator to specify the target  Storage Node WWUI
   to uniquely identify the target storage node. An alias string could
   also be associated with a target storage node. The target alias helps
   an organization to associate their own semantic meaning with the
   target alias string. However, the target alias string is not a
   substitute for the target WWUI.
   3.1 World Wide Unique Identifier
   The WWUI uniquely identifies iSCSI initiators and targets. The
   initiator WWUI corresponds to the logical operating system on which
   the initiator is running, and the target WWUI corresponds to the
   target Storage Node entity.
   A WWUI really names a logical software entity, and is not generally
   tied to a port or other hardware that can be changed.  For instance,
   an initiator WWUI should name the iSCSI initiator driver, and not
   a particular NIC or HBA card.  When multiple NICs are used, they
   should generally all present the same WWUI to the targets, since
   they are really to the same entity.  In most operating systems, the
   named entity is the operating system image.  Most hosts will have a
   single OS running; some of the really big ones could have multiples.
   A target WWUI should similarly not be tied to hardware interfaces
   that can be changed.  A WWUI should identify the logical target,
   and must be the same for the target regardless of the physical port
   on which it is addressed.  This gives iSCSI initiators an easy way
   to determine that two targets it has discovered are really two paths
   to the same target.
   The iSCSI WWUI is designed to fulfill the functional requirements
   for Uniform Resource Names (URN) [RFC1737].  Among these requirements
   are that the WWUI must have a global scope, independent of address
   or location, and that it be persistent and globally unique.  It must
   be extensible, and scale with the use of naming authorities.  The
   encoding of the WWUI should be transcribable by a human, as well as
   be machine-readable.  There are other requirements as well; please
   read RFC1737 (only 5 pages) for definitions of these requirements.
   The WWUI may be displayed by user interfaces, but is generally
   uninterpreted and used as an opaque, case-insensitive string for
   comparison with other WWUI values.
   A WWUI is text-based.  This was done for the following reasons:
     - A text-based identifier is transcribable, and is easier to
   Voruganti iSCSI Naming and Discovery - Expires August 2001        4
       differentiate when looking at a user interface, or while
       debugging problems with iSCSI login and discovery.
     - WWUIs are only used during login and discovery phases, so the
       overhead does not get in the way of the data path.
     - The iSCSI protocol communicates these via text strings anyway,
       so it "fits in" easily.
   A WWUI consists of three parts: a type designator, followed by a
   naming authority, with the remaining format designated by the naming
   authority itself, subject to the following requirements.
   A WWUI can be any Unicode character string with the following
      - it is in Normalization Form C (see Unicode Standard Annex #15,
        "Unicode Normalization Forms" at
      - it contains only the ASCII dash character ('-'=U+002d) or the
        ASCII dot character ('.'=U+002e) or is in one of the following
        General Categories:
          a) Lu (Letter, Uppercase)
          b) Ll (Letter, Lowercase)
          c) Lt (Letter, Titlecase)
          d) Lm (Letter, Modifier)
          e) Lo (Letter, Other)
          f) Nd (Number, Decimal Digit)
          g) Nl (Number, Letter)
          h) No (Number, Other)
      - when encoded in UTF-8, it is no more than 255 bytes
   In particular, white space, punctuation (except as noted), marks and
   symbols are not allowed.
   When included in Text or Login messages, a WWUI SHALL be formatted in
   UTF-8 form.
   For the purposes of comparison, computing hash values, or anything
   else that operates on a WWUI, the WWUI must first be converted to
   lower-case in a locale-independent manner (case-folding) per the
   rules described in Unicode Technical Report #21, "Case Mappings",
   section 2.3 "Caseless Matching" (see
   When inserting a WWUI into a URI format to be used as either a URL
   or a URN, the following transformations should take place.  The WWUI
   should be first converted to a UTF-8 string.  Then the rules of RFC
   2396 (excluded characters) and RFC 2732 (re-allowed characters) SHALL
   be applied to convert this byte string into an allowable URI ASCII
   string. This process is invertable so there is no loss of
   information.  The format for an iSCSI URN is specified in [20].
   Voruganti iSCSI Naming and Discovery - Expires August 2001        5
   Since there are different types of naming authorities, there are
   different types of WWUIs to make use of them.  Each WWUI is
   prefixed with a short type designator string that indicates the
   type of naming authority being used.
   Here are the type designator strings that may currently be used:
         iscsi      - Not unique; indicates a "canonical" target or
         iscsi.     - Naming authority is a reverse DNS name
         eui.       - Remainder of the string is an EUI-64 address.
         oui.       - Naming authority is a 24-bit Organizationally
                      Unique Identifier.
         dns.       - A format tied to a particular DNS address as
                      a naming authority.
   The creation of additional type designator strings must be done
   via the IETF IPS working group.  Use of type strings not listed
   here is not allowed, as they cannot be guaranteed to be unique.
   The use of the naming authority means that WWUIs can be assigned by
   virtually any uniqueness scheme that can be devised by OS vendors,
   driver or iSCSI NIC vendors, device vendors, gateway vendors, and
   even the customer.
   The WWUI scheme's use of naming authorities is designed to fulfill
   RFC 1737 "Functional Requirements for Uniform Resource Names".
   A WWUI can be incorporated into a Uniform Resource Name (URN) by
   methods shown later in this document.
   Type "iscsi"
     This type does not specify a real WWUI; it is used during login
     as a default or canonical WWUI.
     Example WWUI:
     This type does not use a naming authority, and so is not a real
     WWUI.  Every device allowing target connections will support this
     as a default target, so it is not world-wide unique.  Every device
     supporting the "iscsi" WWUI should also support an actual WWUI of
     one of the other three types.
   Type "iscsi." (reverse DNS naming authority format)
     This WWUI type can be used by either a manufacturer, end user,
     or service provider.  This naming authority is handy especially
     when an end user or service provider wishes to provide the WWUI
     for a target.  These customers all own DNS domains; the same is
     not true for OUI, SCSI Vendor ID, or any of the other assigned
     identifiers that could be used as a naming authority.
   Voruganti iSCSI Naming and Discovery - Expires August 2001        6
     The Text WWUI string is defined as follows:
     After the "iscsi.", the string starts with a backwards domain
     name specifying the Naming Authority, using dots as separators,
     just as in a regular domain name.  It's backwards, since it is
     not really used as a fully qualified host name; only the necessary
     top levels need by used.
     Basically, everything after the backwards domain name, followed
     by another dot ".", can be assigned as needed by the owner of
     the domain name.
     Here is an example Text WWUI string:
        "iscsi" defines that the Naming Authirity is in the DNS string.
        "com.acme" defines the Naming Authority.  The owner of the DNS
        name "acme.com" has the sole right of use of this name within
        a WWUI, as well as the responsibility to keep the remainder of
        the WWUI unique.  In this case, acme.com happens to manufacture
        disk arrays.
        "diskarrays" was picked arbitrarily by acme.com to use to
        identify the disk arrays they manufacture.  Another product
        that ACME makes might use a different name, and have their
        own namespace independent of the disk array group.
        "sn" was picked by the disk array group of Acme to show that
        what follows is a serial number.  They could have just assumed
        that all WWUIs are based on serial numbers, but they thought
        that perhaps later products might be better identified by
        something else.  Adding "sn" was a future-proof measure.
        "a8675309" is the serial number of the disk array, uniquely
        identifying it from all other arrays.
     Please note that WWUI is NOT an address - even though it uses a DNS
     name, this is for the naming authority only; it is not an address
     used to discover anything.
     Note that we could have used the SCSI Vendor ID as a naming
     authority.  However, some large customers and service providers
     may wish to use their own identification scheme, rather than
     that provided by the manufacturer.  These customers would not
     likely have a registered Vendor ID, but the domain name we
     used is ubiquitous, and seemed more appropriate.
     Further examples of DNS WWUIs are given at the end of this
   Voruganti iSCSI Naming and Discovery - Expires August 2001        7
   Type "eui." (IEEE EUI format)
     The IEEE WWUI might be used when a manufacturer is already
     basing unique identifiers on World-Wide Names as defined in
     the SCSI SPC-2 specification.
     It may also be used by a gateway representing a Fibre Channel
     or SCSI device that is already adequately identified using a
     world-wide name.
     The format is "eui." followed by 16 hex digits.
     Example WWUI:
   Type "oui." (Organizationally Unique Identifier)
     The format is "oui.", followed by 6 hex digits specifying the
   naming authority's OUI, followed by whatever format the naming
   authority wishes to use.
     Example WWUI:
   Type "dns." (DNS Address used as a naming authority)
     This format may be used to provide a very localized naming
   authority by adding a fully qualified domain name (FQDN) after the
   "dns.".  This format may be used when generating WWUIs that will not
   change locations, since it includes the host name of the target
   within its format.
     The format is "dns.", followed by the FQDN of the entity providing
     the name, followed by whatever format the naming authority wishes
     to use.
     An advantage of this format is that an address may be extracted
     from it without querying a name server.
     CAUTION: This format includes an address, and therefore does not
     fulfill the global name space requirement for a Uniform Resource
     Name (URN).  Please consider whether one of the other formats
     is appropriate before using this one.
   Initiator and Target Requirements for WWUI support:
   Voruganti iSCSI Naming and Discovery - Expires August 2001        8
     Each initiator and target implementation must support the use
     of a WWUI.
     The initiator MUST send an InitiatorWWUI and a TargetWWUI as text
     fields within the login request.  If the initiator does not have or
     support a WWUI, it must send an InitiatorWWUI of "iscsi".  If the
     initiator is logging in to the canonical (default) target, it must
     specify a TargetWWUI of "iscsi".  Note that if an InitiatorWWUI
     of "iscsi" is used, the initiator stands the risk that it will be
     excluded from accessing some of all of its targets.
     An initiator MAY send an InitiatorAlias as a text field within its
     login request.  The target may use this as an informational field
     only; it must not be used for unique identification or
   authentication purposes.
     The target MUST send a TargetWWUI as a text field within its login
     response.  Unless the initiator specified the TargetWWUI "iscsi"
     in the request, this TargetWWUI MUST match that specified by the
     initiator.  If the initiator had specified a TargetWWUI of "iscsi",
     this TargetWWUI should be the actual WWUI of the target, or can
     be returned as "iscsi" if either the target is just a canonical
     target used for the SendTargets command, or if the target does
     not have a WWUI.
     The target MAY send a TargetAlias as a text field within its login
     response.  The initiator may use this as an informational field
     only; it must not be used for unique identification or
   authentication purposes.
     Initiators and targets shall support the receipt of WWUIs of up to
   the maximum length.  If configuration of the initiator or target WWUI
   is allowed, the implementation shall support the maximum length.
     In their user interfaces, both shall support, at a minimum, the
     display of the ASCII characters within the WWUI UTF-8 string.  If
   the other characters are unsupported, they may be displayed with
   escape codes as specified in [RFC 2396].
   3.2 Alias String
   The alias string is a UTF-8 text string that may be used as an
   additional descriptive name for an initiator and target.  This
   may not be used to identify a target or initiator during login,
   and does not have to follow the uniqueness or other requirments
   of the WWUI.  The alias strings are communicated between the
   initiator and target at login, and can be displayed by a user
   interface on either end, helping the user tell at a glance whether
   the initiators and/or targets at the other end appear to be
   correct.  The alias must NOT be used to identify, address, or
   authenticate initiators and targets.
   Voruganti iSCSI Naming and Discovery - Expires August 2001        9
   The alias is a variable length string, between 0 and 255 characters,
   and is terminated with at least one NULL (0x00) character.  No
   other structure is imposed upon this string.
   3.2.1 Purpose of an Alias
     Initiators and targets are uniquely identified by a World-Wide
     Unique Identifier (WWUI).  These identifiers may be assigned by
     a hardware or software manufacturer, a service provider, or even
     the customer.  Although these identifiers are nominally human-
     readable, they are likely be be assigned from a point of view
     different from that of the other side of the connection.  For
     instance, a target WWUI for a disk array may be built from the
     array's serial number, and some sort of internal target ID.
     Although this would still be human-readable and transcribable,
     it offers little assurance to someone at a user interface who
     would like to see "at-a-glance" whether this target is really
     the correct one.
     The use of an alias helps solve that problem.  An alias is
     simply a descriptive name that can be assigned to an initiator
     or target, that is independent of the WWUI, and does not have
     to be unique.  Since it is not unique, the alias must be used
     in a purely informational way.  It may not be used to specify
     a target at login, or used during authentication.  It is not used
     in place of the old iscsi "path" concept; WWUI is used there
     Both targets and initiators may have aliases.
   3.2.2 Target Alias
     To show the utility of an alias, here is an example using an
     alias for an iSCSI target.
     Imagine sitting at a desktop station that is using some iSCSI
     devices over a network.  The user requires another iSCSI disk,
     and calls the storage services person (internal or external),
     giving any authentication information that the storage device
     will require for the host.  The services person allocates a
     new target for the host, and sends the WWUI for the new target,
     and probably an address, back to the user.  The user then adds
     this WWUI to the configuration file on the host, and discovers
     the new device.
     Without an alias, a user managing an iSCSI host would click
     on some sort of "show targets" button to show the targets to
     which the host is currently connected.
     |  WWUI
   Voruganti iSCSI Naming and Discovery - Expires August 2001       10
     |  com.acme.sn.5551212.target.450
     |  com.acme.sn.5551212.target.489
     |  com.acme.sn.8675309
     In the above example, the user sees a collection of WWUIs, but
     with no real description of what they are for.  They will, of
     course, map to a system-dependent device file or drive letter,
     but it's not easy looking at numbers quickly to see if everything
     is there.
     If a more intelligent target configures an alias for each target,
     perhaps at the time the target was allocated to the host, a more
     descriptive name can be given.  This alias is sent back to the
     initiator as part of the login or sendTargets responses, for use
     in a display such as this.  The new display might look like:
     |  Alias          WWUI
     |  Oracle 1       com.acme.sn.5551212.target.450
     |  Local Disk     com.acme.sn.5551212.target.489
     |  Exchange 2     com.acme.sn.8675309
     This would give the user a better idea of what's really there.
     In general, flexible, configured aliases will probably be
     supported by larger storage subsystems and configurable gateways.
     Simpler devices will likely not keep configuration data
     around for things such as an alias.  The TargetAlias string
     could be either left unsupported (not given to the initiator
     during login) or could be returned as whatever the "next best
     thing" that the target has that might better describe it.
     Since it does not have to be unique, it could even return
     SCSI inquiry string data.
     Note that if a simple initiator does not wish to keep or display
     alias information, it can be simply ignored in the login or
     sendTargets responses.
   3.2.3 Initiator Alias
     An initiator alias can be used in the same manner as a target
     alias.  An initiator would send the alias in a login request,
     when it sends its WWUI.  The alias is not used for authentication,
     but may be kept with the session information for display through
     a management GUI or command-line interface (for a more complex
     subsystem or gateway), or through the iSCSI MIB.
   Voruganti iSCSI Naming and Discovery - Expires August 2001       11
     Note that a simple target can just ignore the Initiator Alias
     if it has no management interface on which to display it.
     Usually just the hostname would be sufficient for an initiator
   alias, but a custom alias could be configured for the sake of the
   service provider if needed.  Even better would be a description of
   what the machine was used for, such as "Exchange Server 1", or "User
   Web Server".
     Here's an example showing a list of sessions on a target device.
     For this display, the targets are using an internal target number,
     which is a fictional field that has purely internal significance.
     |  Target   Initiator WWUI
     |  450      com.sw.cd.12345678-OEM-456
     |  451      com.os.hostid.A598B45C
     |  309      com.sw.cd.87654321-OEM-259
     And with the initiator alias displayed:
     |  Target   Alias                Initiator WWUI
     |  450      Web Server 4         com.sw.cd.12345678-OEM-456
     |  451      scsigate.yours.com   com.os.hostid.A598B45C
     |  309      Exchange Server      com.sw.cd.87654321-OEM-259
     This gives the storage administrator a better idea of who is
     connected to their targets.  Of course, one could always do
     a reverse DNS lookup of the incoming IP address to determine
     a host name, but simpler devices really don't do well with that
     particular feature due to blocking problems, and it won't
     always work if there is a firewall or iSCSI gateway involved.
     Again, these are purely informational and optional.
     Aliases are extremely easy to implement.  Targets just send
     a TargetAlias whenever they send a TargetWWUI.  Initiators just
     send an InitiatorAlias whenever they send an InitiatorWWUI.
     If an alias is received that does not fit, or seems invalid
     in any way, it is ignored.
   4. iSCSI Discovery
   Voruganti iSCSI Naming and Discovery - Expires August 2001       12
   The goal of iSCSI discovery is to allow an initiator to find the
   targets to which it has access (named by their WWUIs), and at least
   one address at which each target may be accessed.  This should
   generally be done using as little configuration as possible.  This
   section defines the discovery mechanism only; no attempt is made
   to specify central management of iSCSI devices within this document.
   There are several methods that may be used to find targets and their
   addresses, ranging from configuring a list of targets and addresses
   on each initiator and doing no discovery at all, to configuring
   nothing on each initiator, and allowing the initiator to discover
   targets via multicast mechanisms.
   An iSCSI initiator can discover iSCSI targets in these ways:
   a. iSCSI targets are configured on the initiator.
   b. The initiator queries iSCSI servers using the SendTargets command.
   c. The initiator queries a storage name server, such as iSNS, for
   d. The initiator uses the Service Location Protocol (SLP) to find
      iSCSI targets, iSCSI servers, and storage name servers.
   4.1 Configuring Target Information
   The exact manner in which the target information is hard-coded at the
   initiator is an implementation detail. The information could be
   present in some persistent location (such as a file) that can be
   accessed by the initiator.
   Target discovery can be configured on an initiator in several ways:
     - Full Target URL.  This includes the target's IP address or host
       name, TCP port, and WWUI.  No further discovery is required to
       contact this target.
     - Target WWUI.  This includes only the target's WWUI, and contains
       no address information.  The initiator must query SLP or a name
       server to locate this target.
     - Canonical Target WWUI.  This is just an iSCSI server's IP address
       and TCP port, the canonical WWUI "iscsi".  The initiator must
       connect to this address, log in to the canonical target, and
   issue a SendTargets command to acquire the list of targets it can
     - Storage Name Server Address.  This is an address of a storage
   name server, such as iSNS, that the initiator may query to find more
       targets.  The information required to configure an initiator for
   a storage name server is outside the scope of this document.
   4.2 SendTargets Command
   Voruganti iSCSI Naming and Discovery - Expires August 2001       13
   An initiator may connect to an iSCSI address (IP address + TCP port)
   and log in to the canonical target WWUI "iscsi".  The login process
   for this target is identical to that of any other target.  If there
   are no targets available that would provide access to the initiator's
   WWUI, the target SHOULD reject the initiator's login to the canonical
   target with the status code set to 0x42 "forbidden target".
   Upon successful login to the "iscsi" target, the initiator may send
   the text command "SendTargets", to retrieve a list of target WWUIs
   to which it may attempt login.
   The canonical target MUST support this command, and MUST return a
   list of zero or more target WWUIs.  Each WWUI returned may include
   zero or more TargetAddress fields, as well one optional TargetAlias
   field.  If zero WWUIs are returned, the canonical target is unaware
   of any targets
   that are accessible by the initiator.
   The command is sent by formatting an iSCSI Text Command, with the
   Final (F) bit set to 1.  The first key in the command's text must
   No value is sent for the send-targets key, and no other keys are
   The response to this command is a text response containing a
   list of text keys.  Each target starts with one text key of the
   It may then include zero or more address keys:
   It may then include the optional target alias key:
   This example is the SendTargets response from a single target,
   that has no other interface ports, and does not support an alias:
   Note that all it really had to return in the simple case was the
   WWUI.  It is assumed by the initiator that the IP address and TCP
   port for this WWUI are the same as used on the current connection
   to the canonical iSCSI target.
   The next example has two internal iSCSI targets, each support via
   two different ports with different IP addresses:
   Voruganti iSCSI Naming and Discovery - Expires August 2001       14
     TargetAlias=Oracle disk four
     TargetAlias:Oracle disk five
   Note that both targets share both addresses; the multiple addresses
   are likely used to provide multi-path support.  The initiator may
   connect to either targetWWUI on either address.
   Also note that in the above example, a DNS host name could have
   been returned instead of an IP address, and that an IPv6 addresses
   (5 to 16 dotted-decimal numbers) could have been returned as well.
   After obtaining a list of targets in this manner, an iSCSI initiator
   may create new sessions to log in to the discovered targets.  The
   initiator MAY keep the session to the canonical target open, and MAY
   send subsequent SendTargets commands to discover new targets.  The
   target MUST send any iSCSI-level async event notifications on this
   session, to allow the initiator to discover new targets as they are
   4.2.1 Redirect Responses
   If a target has moved, or if the iSCSI device logged in to has
   knowledge of another address at which a target should be accessed,
   it MAY return a redirect response by setting the iSCSI login status
   to one of the 0x3x status codes, and returning at least one text
   key with a new target address on which to find the target.  This
   status terminates the session.
   The initiator, upon receiving a redirect response, SHOULD either
   abandon attempts to log in to the intended target, or attempt to
   re-login to the target using one of the addresses provided.
   A target might do this for load balancing or it might do this to
   multiple virtual targets through a simple initiator discovery
   The target's response includes the WWUI of the target, plus one
   or more TargetAddress fields, as specified in the SendTargets
   Here's a simple example:
            T->Login Response(status=3x)
   Voruganti iSCSI Naming and Discovery - Expires August 2001       15
   In the above example, a new address exists for the target WWUI at, TCP port 3000.  If the TCP port was not specified, it
   would use the default port (to be assigned by IANA).
   Another example would include multiple addresses for a target,
   through multiple ports on a storage controller, or through multiple
            T->Login Response(status=3x)
   Note that the address may be either an IP address or DNS host name.
   The first and third addresses to not include a TCP port; these would
   use the default, IANA-assigned TCP port.
   In any case, the TargetWWUI returned is identical to that requested
   by the initiator in the initial Login Request.  The redirect status
   is not used to change WWUIs; it is only used to move a WWUI from
   one IP address and/or TCP port to another.
   4.3 Initiator queries a Storage Name Server (SNS)
   Discovery and management of iSCSI devices can be extended by the use
   of Storage Name Servers (SNS).  The term "SNS" used in this document
   should not be confused with the specific implementation used in
   Fibre Channel; it is meant to be a generic term.
   An SNS can add capabilities beyond discovery of iSCSI targets, but
   for the purposes of this section it must at least provide a method of
   1. The addresses at which a particular WWUI may be found
   2. A list of WWUIs and/or addresses to which the initiator has access
   To make use of an SNS, an initiator must support a protocol that
   provides SNS query facilities.
   4.4 Initiator Uses the Service Location Protocol
   A storage name server address may be either configured, or discovered
   through SLP.
   An initiator may use the Service Location Protocol, Version 2 (SLPv2)
   to locate iSCSI targets, canonical targets, and storage name servers,
   without having to configure their addresses.  SLP Version 1 is not
   supported by iSCSI.
   Voruganti iSCSI Naming and Discovery - Expires August 2001       16
   The Service Location Protocol (SLP) is a standard protocol for
   locating the addresses of resources on a network.  iSCSI targets,
   canonical targets, and storage name servers may advertise themselves
   to iSCSI initiators using SLP.
   Three types of nodes participate in SLP discovery.  A User Agent (UA)
   is the entity that wishes to discover resources.  In this case, the
   UA is part of the iSCSI initiator.  A Service Agent (SA) is the
   entity that wishes to be discovered.  In our case, the SA is part of
   the iSCSI target, canonical target, or storage name server.  A third
   entity, the
   Directory Agent (DA) is an optional part of discovery.  If a DA is
   present, it collects information about the Service Agents, and is
   queried by the User Agents, to reduce the network load of all UAs
   trying to discovery all SAs.
   For true zero-configuration, SLP makes use of multicast to locate DAs
   or SAs.  However, SLP is designed to use as little multicast traffic
   as possible, and by using a DA, and configuring its address on each
   initiator, will not require multicast at all.
   The SLP Protocol is described in detail in [RFC2608].
   A target can register either its canonical target address, its
   targets themselves, or both with SLP.  A storage name server can
   register its address with SLP, or can also register its targets
   with SLP, if desired.
   Initiators can send the following service requests using SLP:
   1. Locate all canonical targets ("iscsi")
   2. Locate specific targets to which the initiator might have access
   3. Locate a specific target by WWUI
   4. Locate storage name servers
   In addition, a storage name server can act as an initiator and make
   use of SLP to discover targets and canonical targets for its own use.
   If a specific target is found, the initiator may simply attempt to
   log in to that target.  An initiator supporting a storage name
   service may additionally query the SNS for more information on the
   target before logging in.  Note that the same target may exist at
   more than one address; it is the responsibility of the initiator to
   ensure that the targets' WWUIs are compared, and that either only
   one address is used, or that some form of multi-path software is
   in place.
   If a canonical target is found, the initiator may log in to the
   canonical target, and issue a SendTargets command as described in
   the previous section.
   If a storage name server is found, and the initiator supports the
   Voruganti iSCSI Naming and Discovery - Expires August 2001       17
   use of this type of storage name server, the initiator may query
   the SNS as described by its particular protocol specification.
   In general, if an initiator supports an SNS, it should normally
   not attempt to discover targets and canonical targets via SLP; it
   should first attempt to discover the SNS itself, and query the SNS
   for this information.
   The choice of static configuration, SNS discovery or target storage
   discovery protocols is a configuration choice of the initiator.
   In summary, this discovery approach is flexible in that the
   initiators have the freedom to select static configuration, a
   multicast based discovery mechanism for small, isolated iSCSI
   environments, or they can choose a scalable storage name server based
   discovery mechanism for large iSCSI environments.
   Additionally, targets and initiators may be configured to participate
   or not participate in an SLP Scope, which allows the SLP discovery
   environment to be contained within a smaller group.
   The Service Location Protocol uses templates, registered with IANA,
   to define the addresses and attributes that are communicated via
   SLP.  The SLP templates implementation details are provided in [21]
   draft-bakke-iscsi-SLP-template.00, but a brief summary is as follows:
      Service:iscsi - A top-level abstract template, which is just a
   name under which to place our other templates.
      service:iscsi:target - A concrete target template, which defines
   the addresses and attributes for iSCSI targets and canonical targets.
      service:iscsi:name-service - A concrete target template, which
   defines the addresses and attributes for storage name services.
   5.  Storage Name Server (SNS)
   The following section describes requirements for any Storage Name
   Server used to support iSCSI.  An example of a Storage Name Server is
   the iSNS described in the draft document draft-ietf-ips-iSNS-00.txt
   [8]. There potentially could be other protocols which also satisfy
   SNS requirements.
   5.1  Overview
   A SNS shall be architected using a client-server paradigm, with a SNS
   server predominantly serving a passive role. SNS clients actively
   register and manipulate entity objects and their attributes in the
   SNS server.  A SNS server MAY send asynchronous state change
   notifications to registered SNS clients in response to an action by a
   Voruganti iSCSI Naming and Discovery - Expires August 2001       18
   SNS client.  Examples of SNS clients include initiators, targets,
   management stations, and switches.  A SNS server can be hosted on a
   target, switch, or stand-alone server.
   5.2  Login Control and Discovery Domains
   Discovery Domains (DD's) are logical groupings of iSCSI devices that
   are allowed to "see" each other. SNS MUST support Discovery Domains
   and Login control. SNS must provide SNS clients with the ability to
   Enforce Discovery Domain configurations which may exist on a SNS
   server.  Targets and management stations shall be able to register
   (i.e., upload) Login Control and Discovery Domain configurations to
   the SNS if authorized by the end user. Discovery Domains and Login
   control supports two separate purposes:
   5.2.1  Discovery Domain Partitions
   A SNS SHALL support the ability to partition the storage network into
   Separate "Discovery Domains".  A SNS shall not provide information if
   the SNS client performing the query is not in a common Discovery
   Domain (DD) as the SNS client that is the subject of the request.
   This capability prevents an initiator from attempting an iSCSI login
   to every single target in a large enterprise network, and is the
   iSCSI equivalent of "Soft" zoning.
   5.2.2  Login Control
   Login access security which is specified in the iSCSI
   Draft (Appendix A) [7] and may be implemented by the iSCSI target.  A
   SNS shall support login control by storing a mapping of initiators
   that are permitted to access each target.  Targets shall be able to
   query the SNS for a list of initiators that are allowed login access.
   This list shall include the key attribute (e.g., WWUI) used to
   identify the initiator.  This capability is the iSCSI equivalent of
   "Hard" zoning.
   5.3    Object Model
            A SNS MUST store the following objects and attributes:
                Network Entity:
                  -  Entity Identifier
                  -  Management IP Address
                  -  Entity Type (iSCSI)
                  -  IP Address
                  -  TCP Port Number
                Storage Node:
                  -  WWUI
                  -  Alias
   Voruganti iSCSI Naming and Discovery - Expires August 2001       19
                  -  Node Type (target or initiator or both)
                Discovery Domain:
                  -  DD symbolic name
                  -  DD ID
                  -  DD Member:  WWUI
                  -  DD Member:  IP Address
            A diagram of how the above objects are related is shown
   |                         IP Network                             |
                |                                      |
                |                                      |
   +-----+------+------+-----+            +-----+------+------+-----+
   |     | PORTAL      |     |            |     | PORTAL      |     |
   |     | -IP Addr 1  |     |            |     | -IP Addr 2  |     |
   |     | -TCP Port 1 |     |            |     | -TCP Port 2 |     |
   |     +-----+ +-----+     |            |     +-----+ +-----+     |
   |           | |           |            |           | |           |
   |           | |           |            |           | |           |
   |  +--------+ +--------+  |            |   +-------+ +--------+  |
   |  |                   |  |            |   |                  |  |
   |  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  |
   |  |  -WWUI            |  |            |   |   -WWUI          |  |
   |  |  -Alias: "server1"|  |            |   |  Alias: "disk1"  |  |
   |  |  -Type: initiator |  |            |   |   -Type: target  |  |
   |  |                   |  |            |   |                  |  |
   |  +-------------------+  |            |   +------------------+  |
   |                         |            |                         |
   |    NETWORK ENTITY       |            |    NETWORK ENTITY       |
   |   -Entity ID (DNS):     |            |   -Entity ID (DNS):     |
   |    "strg1.foo.com"      |            |    "strg2.bar.com"      |
   |   -Type: iSCSI          |            |   -Type: iSCSI          |
   |                         |            |                         |
   +-------------------------+            +-------------------------+
            A DISCOVERY DOMAIN contains one or more NETWORK ENTITY,
   and/or STORAGE NODE,  objects.  Each NETWORK ENTITY object contains
   one or more PORTAL objects, and one or more STORAGE NODE objects.
   5.4  SNS Message Format Requirements
   The SNS protocol SHALL  be TLV based.
   TLV (TLV is already used in many networking protocols such as DHCP).
   The SNS protocol shall allow manipulation of multiple objects and
   attributes in a SNS server through a single message and response.
   5.5  SNS Authentication Requirements
   Voruganti iSCSI Naming and Discovery - Expires August 2001       20
   The SNS protocol SHALL include optional authentication of SNS
   protocol messages from SNS clients. The authentication mechanism will
   allow for authentication of both client and server.
   5.6 SNS Query and Registration Services Requirements
   The SNS protocol allows initiators and targets to register themselves
   at The SNS server. Initiators and targets can also query a SNS server
   for information. For example, targets can register themselves at a
   SNS server, and the initiators can query a SNS server about which
   targets they can access.
            During registration, the initiators and the targets must
   provide the following information:
            a) Portal object address (IP address and Port Number)
            b) WWUI information
            c) Storage node type
            They could optionally also provide other information such
            a) Storage Entity ID
            b) Alias string information
            c) Registration for State Change Notification
            If the Storage Entity ID is not provided in the initial
   registration, then a SNS shall create a unique Entity ID for that
   client, and the client shall use that Entity ID for all subsequent
   queries and updates.
            When querying address information in order to establish an
   iSCSI connection, the query, as a minimum, should return the
   following information:
   a) Storage Entity IP address
   The Portal Object IP address can be the same as the Storage Entity IP
   address, and the Portal Object port number can be the (TBD) default
   iSCSI port number. Furthermore, the WWUI of the target device can be
   queried by issuing the  SendTarget command to the default canonical
   iSCSI target present at the IP address and port number.
   5.7  State Change Notification Requirements
   Asynchronous notification (State Change Notifications):  A SNS must
   be able to inform SNS clients of changes to its database, including
   changes or modifications to Discovery Domain or login control
   policies and the presence or absence of initiators and targets.
   These changes may occur as a result of various events, including an
   SNS client (e.g., a management workstation) actively changing the SNS
   database, response or non-response to an SNS status inquiry message,
   or a hardware interrupt delivered by a SNS host platform (such as a
   switch). Asynchronous notification shall be delivered only to SNS
   clients that register for the notification, and only for SNS clients
   that are in the same Discovery Domain as the event.
   Voruganti iSCSI Naming and Discovery - Expires August 2001       21
   5.8  The SNS protocol SHALL be a lightweight protocol that can be
   scaled down for implementation on switches and targets, or scaled up
   for implementation on servers.
   5.9  The SNS protocol SHALL meet the iSCSI boot requirements (see
   6.   iSNS - Internet Storage Name Service
   iSNS is a name service protocol which can be used for discovery and
   management of iSCSI devices.  The iSNS protocol is described in the
   document draft-ietf-ips-iSNS-01.txt, and meets the requirements of
   section 5 of this document.  The following section describe how iSNS
   is used to support iSCSI devices.
   6.1  iSCSI Requirements for iSNS
   iSNS MAY be used to fulfill iSCSI Naming and Discovery Requirements.
   Section 5.1 of the iSNS document lists specific implementation and
   usage requirements for iSCSI.  Sections 5.2 and 5.3 are applicable to
   non-iSCSI protocols, and do NOT have to be implemented to support
   iSCSI.  The remaining sections of the iSNS document provide important
   background and protocol format information which are generally
   applicable to an iSNS implementation that supports iSCSI.  One
   exception is the RqstDmnID and RlsDmnID commands, which are used to
   support Fibre Channel and iFCP fabrics.
   6.2  Summary of iSNS Features & Capabilities
   The following are a summary of iSNS capabilities used to support
   6.2.1   iSNS Registration Service
   iSNS allows iSCSI devices to register their identity and attributes
   in the iSNS database.  Multiple attributes can be registered in a
   single message. This allows management stations to directly manage
   large numbers of iSCSI devices by accessing the iSNS as a single,
   consolidated information repository.
   6.2.2   Discovery Domains (DD's)
   iSNS organizes iSCSI devices into logical groups.  This accomplishes
   two primary purposes:  1)  it limits the targets visible to each
   initiator to the more relevant and appropriate subset of devices in
   the entire storage network universe;  2)  it eases administration by
   partitioning storage devices into smaller, more manageable groups.
   6.2.3   iSCSI Device Query Service
   Voruganti iSCSI Naming and Discovery - Expires August 2001       22
   iSNS responds to queries from iSCSI devices requesting information
   about other iSCSI devices residing in a common Discovery Domain.
   Multiple attributes can be queried for in a single message.
   6.2.4   State Change Notification (SCN's)
   A network event, such as removal of another device from a common
   Discovery Domain, will cause the iSNS to send an asynchronous
   notification message of the event to iSCSI devices that have
   registered for such a notification.
   6.2.5   Distribution and Retrieval of Public Key Certificates
   iSNS provides a convenient mechanism to distribute X.509 Public Key
   certificates.  These certificates can be used to set up TLS or IPSec
   security associations for authenticating and/or encrypting storage
   traffic, as well as for the Public Key authentication method in the
   iSCSI login process.  iSCSI devices can upload their own Public Key
   Certificates, allowing other iSCSI devices in their Discovery Domain
   to retrieve them.
   6.2.6   Entity Status Inquiry (ESI)
   iSNS provides a polling service to detect the removal or loss of
   connectivity to iSNS clients.  iSCSI devices that register for ESI
   will receive an inquiry message from the iSNS server at regular time
   intervals. If the iSCSI device does not respond to three consecutive
   ESI messages, the iSNS server will determine that the iSCSI device is
   no longer available. Appropriate SCN messages will be sent to
   affected devices in the Discovery Domain.
   6.2.7   Event Logging
   iSNS provides an SCN Event Bitmap attribute for each iSCSI device
   allowing a management client to learn the last State Change
   Notification event to occur to that device.  The Timestamp attribute
   records the precise time of the latest SCN event.
   6.2.8   Name Service Heartbeat
   iSNS provides a regular local subnet broadcast that allows iSCSI
   devices in the local network to passively listen for and learn the IP
   address of the iSNS server.
   6.2.9   Network Time Service
   iSNS provides an optional network time service allowing iSCSI devices
   to synchronize their time to the clock used by the iSNS.
   6.3  iSCSI Attributes Supported by iSNS
   The following attributes are supported by the iSNS protocol.
   Attributes indicated in the "REQUIRED TO IMPLEMENT" column MUST be
   supported by a server compliant with the iSNS protocol.  Attributes
   indicated in the "REQUIRED TO USE" column MUST have values stored for
   an iSCSI device registered in the iSNS server.
                                               REQUIRED     REQUIRED
   Voruganti iSCSI Naming and Discovery - Expires August 2001       23
   Object                Attribute           to Implement    to Use
   ------                ---------           ------------   --------
   NETWORK ENTITY     Entity Identifier            *           *
                      Entity Type                  *           *
                      Management IP Address
                      ESI Interval                 *
                      Timestamp                    *
                      Entity Certificate           *
                      SCN Event Bitmap             *
                      ESI TCP/UDP Port             *           *
   PORTAL             IP Address                   *           *
                      TCP/UDP Port                 *           *
                      Portal Symbolic Name         *
   STORAGE NODE       WWUI                         *           *
                      Node Type                    *           *
                      Alias/Symbolic Node Name     *
                      Node Certificate             *
   DISCOVERY DOMAIN   DD_ID                        *           *
                      DD_Symbolic Name             *
                      DD Member (Entity ID)        *
                      DD_Member (WWUI)             *           *
                      DD_Member (IP Address)       *
   6.4   iSNS Message Summary
   The following messages are used by iSNS to support iSCSI devices.
   Messages listed in the "REQUIRED TO IMPLEMENT" column MUST be
   supported in the iSNS server.  Messages listed in the "REQUIRED TO
   USE" column MUST be supported in the iSCSI device using iSNS.
                                                     REQUIRED TO:
      Message Description    Abbreviation  Func_ID  Implement  Use
      -------------------    ------------  -------  ---------  ---
   Register Dev Attr Req     RegDevAttr    0x0001       *       *
   Dev Attr Query Request    DevAttrQry    0x0002       *       *
   Dev Get Next Request      DevGetNext    0x0003       *
   Deregister Dev Request    DeregDev      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   Register DD               RegDD         0x0009       *       *
   Deregister DD             DeregDD       0x000A       *       *
   Register Dev in DD        RegDevDD      0x000B       *       *
   Deregister Dev in DD      DeregDevDD    0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E
   NOT USED                                0x000F
   Request Network Time      RqstTime      0x0010
   NOT USED                                0x0011-0x0012
   Voruganti iSCSI Naming and Discovery - Expires August 2001       24
   RESERVED                                0x0013-0x8000
   The following are iSNSP response messages used in support of iSCSI:
                                                     REQUIRED TO:
   Response Message Desc     Abbreviation  Func_ID  Implement  Use
   ---------------------     ------------  -------  ---------  ---
   Register Dev Attr Rsp     RegDevRsp     0x8001       *       *
   Dev Attr Query Resp       DevAttrQryRsp 0x8002       *       *
   Dev Get Next Resp         DevGetNextRsp 0x8003       *
   Deregister Dev Resp       DeregDevRsp   0x8004       *       *
   SCN Register Resp         SCNRegRsp     0x8005       *
   SCN Deregister Resp       SCNDeregRsp   0x8006       *
   SCN Event Resp            SCNEventRsp   0x8007       *
   SCN Response              SCNRsp        0x8008       *
   Register DD Resp          RegDDRsp      0x8009       *       *
   Deregister DD Resp        DeregDDRsp    0x800A       *       *
   Register Dev in DD Resp   RegDevDDRsp   0x800B       *       *
   Deregister Dev in DD Resp DeregDevDDRsp 0x800C       *       *
   Entity Stat Inquiry Resp  ESIRsp        0x800D       *
   NOT USED                                0x800E-0x800F
   Request Net Time Resp     RqstTimeRsp   0x8010
   NOT USED                                0x8011-0x8012
   RESERVED                                0x8013-0xFFFF
   7) Related Work
   Jini [1], and PnP [2] and are two other discovery protocols that were
   evaluated as potential iSCSI discovery protocol candidates, but iSCSI
   uses SLP broadcast discovery mechanism. SLP is an IETF approved
   protocol which helps iSCSI to realize the broadcast discovery
   functionality present in Jini and PnP.
   8) Security
      The iSCSI initiators and targets must have a secure way of
   interacting with each other. Hence, once a target or name server is
   discovered, authentication and authorization are handled by either
   the iSCSI protocol, or by the name 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.
   8. Appendix A: iSCSI WWUI Notes
    Some WWUI Examples for Targets
   - Assign to a target based on controller serial number
   Voruganti iSCSI Naming and Discovery - Expires August 2001       25
     See the ASCII WWUI example above for discussion.
   - Assign to a target based on serial number and logical target alias
     Where oracle_database_1 might be a target alias assigned by a user.
     This would be useful for a controller that can present
     different logical targets to different hosts.
     Obviously, any naming authority may come up with its own
     scheme and hierarchy for these names, and be just as valid.
     A target WWUI should NEVER be assigned based on interface
     hardware, or other hardware that can be swapped and moved to other
   Some WWUI Examples for Initiators
   - Assign to the OS image by fully qualified host name
       Note the use of two FQDNs - that of the naming
       authority and also that of the host that is being
       named.  This can cause problems, due to limitations
       imposed on the size of the WWUI.
       ( write in what to do about this )
   - Assign to the OS image by OS install serial number
       Note that this breaks if an install CD is used more
       than once.  Depending on the O/S vendor's philosophy,
       this might be a feature.
   - Assign to the OS image by a service provider
       Note that this could also be assigned to a particular
       iSCSI address if more than one service provider is used.
   Using Initiator and Target WWUI During Login
     Some examples.
   Voruganti iSCSI Naming and Discovery - Expires August 2001       26
   1. Login to a known target WWUI; initiator supports WWUI.
      I->Login Request
         InitiatorWWUI= iscsi.com.os.hostid.34567890
         InitiatorAlias= myhost
         TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
            .  text/login commands flow here during authentication phase
      T->Login Response
         TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
         TargetAlias= foo
   2. Login to an unknown target WWUI; initiator supports WWUI.
      This only works if there is a single WWUI at the IP address
      and TCP port to which the initiator has connected.
      I->Login Request
         InitiatorWWUI= iscsi.com.os.hostid.34567890
         InitiatorAlias= myhost
         TargetWWUI= iscsi
            .  text/login commands flow here during authentication phase
      T->Login Response
         TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
         TargetAlias= 8675309
   3. Login to a canonical target, for the SendTargets command.
      I->Login Request
         InitiatorWWUI= iscsi.com.os.hostid.34567890
         InitiatorAlias= myhost
         TargetWWUI= iscsi
            .  text/login commands flow here during authentication phase
      T->Login Response
         TargetWWUI= iscsi
      Since the target returned a WWUI of "iscsi", the initiator will
      now use the SendTargets text command to find out which target
      are actually supported at this address.  It will then create
      new connections for each target, and do the login scenario shown
      in example 1.
      [ What if this is a really simple device with no WWUI, and no
        SendTargets?  At this point, the initiator could just be logged
        in and start doing stuff, but what's the rule it should use
        to know that?  Or is it silly not to have a WWUI, since even a
        single disk or tape drive will have something to make one out
   Voruganti iSCSI Naming and Discovery - Expires August 2001       27
        of? ]
   Answers to Potentially Frequently Asked Questions
    What happens if an Initiator WWUI is not unique?
     - Targets will authenticate both as same entity
     - Targets will believe that one initiator is using
       them via different network interfaces.
     - Initiators may end up sharing a device by
   Appendix B: iSCSI Login Scenarios
   B.1. Introduction
   The Initiator WWUI MUST always be sent during login.  As a target may
   use the Initiator WWUI as part of its access control mechanism, an
   initiator that does not send its WWUI stands the risk that it will be
   excluded from accessing some or all of its targets.
   The target WWUI MUST be sent in the login phase (with the exception
   that the key-word iscsi can replace unknown target). This can enable
   the distinction between several (virtual of physical) storage
   entities in the device.
   The WWUIs MUST be sent in the Login Request message, establishing the
   login session (together with the other login parameters). The WWUIs
   MUST be in text command format - UTF-8 coded as described in chapter
   The target MUST response to the login request with the appropriate
   status. The status codes are defined in the iSCSI draft [7].
   B.2. Request Format
   The requests and responses are in key:value format. When more than
   one Value is required, a comma separator is used, i.e.,
   The key words are:
   |  Key             |    Description       |
   |  InitiatorWWUI   |    Initiator's WWUI  |
   |  TargetWWUI      |    Target's WWUI     |
   |  TargetAlias     |    Target's Alias    |
   |  InitiatorAlias  |    Initiator's Alias |
   |  TargetAddress   |    Target IP:Port    |
   Voruganti iSCSI Naming and Discovery - Expires August 2001       28
   In the Login Request command, the initiator uses the keys and the
   appropriate WWUI as values. For example:
   I->Login Request
        InitiatorWWUI= iscsi.com.os.hostid.34567890
        InitiatorAlias= myhost
        TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   Here, both initiator and target WWUI are presented. Other parameters
   (security, negotiation) MAY be added.
   In the following example, only the initiator's WWUI is presented (the
   key-word iscsi is used):
   I->Login Request
        InitiatorWWUI= iscsi.com.os.hostid.34567890
        TargetWWUI= iscsi
   Other parameters (security, negotiation) MAY be added.
   B.3. Response Format
   The response to the login request can be to accept the request, to
   reject it or to proceed for further processing (authentication). This
   status should be reflected on the response message.
   B.4. Examples
   B.4.1 Successful login, known target:
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      InitiatorAlias= myhost
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   If no further process is needed:
   T->Login Response ("login accept 00", F set)
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
      TargetAlias= foo
   Or, if more authentication and/or negotiation is required:
   T->Login Response ("challenge 20", F clear)
       . authentication/negotiation
   T->Login Response ("login accept", F set)
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
      TargetAlias= foo
   In this case, target WWUI is specified in the request. The response
   Voruganti iSCSI Naming and Discovery - Expires August 2001       29
   Reflects the WWUIs, indicating successful login. Target Alias MAY be
   B.4.2 Successful login, unknown target:
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      InitiatorAlias= myhost
      TargetWWUI= iscsi
       . authentication/negotiation
   T->Login Response ("login accept", F set)
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
      TargetAlias= foo
   If there is a single WWUI at the IP address and TCP port to which the
   initiator has connected, this will work.  The target returns its WWUI
   so the initiator can keep it for future use.
   Note that in the case of partial response, the target WWUI is
   reflected Only after the authentication process.
   B.4.3 Login to a canonical target, for the SendTargets command.
   The initiator MUST use the key word iscsi as target's WWUI:
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      InitiatorAlias= myhost
      TargetWWUI= iscsi
       . authentication/negotiation
   T->Login Response ("login accept", F set)
      TargetWWUI= iscsi
   Since the target returned a WWUI of "iscsi", the initiator MAY now
   use the SendTargets text command to find out which target WWUIs are
   actually supported at this address. It will then create new
   connections for each target, and do the login scenario shown in
   B.4.4 Redirection
   If a target has moved, or is accessible only via a proxy, the target
   may respond with one of several redirection status codes, along with
   one or more TargetAddress fields specifying the new location(s) of
   the target.
   Note that a "moving target" is not changing its identity, or WWUI. It
   is only changing its address.  A target returning a redirect status
   Voruganti iSCSI Naming and Discovery - Expires August 2001       30
   SHOULD also include one or more TargetAddress fields specifying the
   new locations of the target.
   For example, if the target moved temporarily:
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      InitiatorAlias= myhost
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
       . authentication/negotiation
     T->Login Response ("Target moved temporarily 31", F set)
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
      TargetAddress= storage1.mydata.com
   (The same goes for the permanent move - code 32). Note that if TCP
   port is not specified, the canonical port is assumed.
   The login response terminates the session and the initiator SHOULD
   start a new login session with the forwarded target. Further
   parameters MAY be reflected on other key=value pairs.
   Or, if a proxy is required for this target:
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      InitiatorAlias= myhost
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
       . authentication/negotiation
   T->Login Response ("Proxy required 33", F set)
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   If more than one proxy exist, their addresses can be reflected in a
   list format.
   B.4.5 Login fail
   In case of login failure - forbidden target, unauthorized initiator
   and so on, the target terminates the session.
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   T->Login Response ("forbidden target 42", F set)
   In this example, the initiator is not allowed on the required target.
   The initiator SHOULD terminate the login session and MAY try
   connecting to another target.
   Voruganti iSCSI Naming and Discovery - Expires August 2001       31
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   T->Login Response ("Target removed 44", F set)
   In this case the target has been removed. In contrast with codes 31
   and 32 (in B.4.4), no redirection information is supplied.
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   T->Login Response ("Target Conflict 45", F set)
   Here, the target is busy with another initiator and cannot handle
   another one. The initiator MAY try again later. This can be the case
   of simple devices that can handle one device or the target has
   reached the limit of its initiators' capacity. In contrast to the
   previous examples, this rejection is temporary.
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   T->Login Response ("Target removed 44", F set)
   Here, the target has been removed. The initiator SHOULD terminate the
   login session. It MAY query the SNS for the new location of the
   target. (This should apply for the case when the target was not found
   - code 44).
   In any case of the 4x and 5x class, there is no WWUI reflection on
   the Login response. However, detailed messages can be carried on
   other key=value pairs.
   B.4.6 Proxy Login
   When the initiator logs to a target via an (iSCSI) proxy, the
   following procedure is applied:
   The initiator connects to the proxy's port and sends a login request
   of the destination target's WWUI and address:
   I->Login Request
      InitiatorWWUI= iscsi.com.os.hostid.34567890
      TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
   Using the TargetAddress key saves the discovery process of the
   target. The proxy logs into the required target with the initiator's
   WWUI. The results of the login are reflected back to the initiator.
   Note that a transparent (iSCSI) proxy does not have a WWUI of its
   Voruganti iSCSI Naming and Discovery - Expires August 2001       32
   Appendix C: iSCSI Proxies and Firewalls Taxonomy
     iSCSI has been designed to allow SCSI initiators and targets
     to communicate over an arbitrary network.  This, making some
     assumptions about authentication and security, means that in
     theory, the whole internet could be used as one giant storage
     However, there are many access and scaling problems that would
     come up when this is attempted.
     1. Most iSCSI targets are only meant to be accessed by one or
        a few initiators.  Discovering everything would be silly.
     2. The initiator and target may be owned by separate entities,
        each with their own directory services, authentication, and
        other schemes.  An iSCSI-aware proxy may be required to
        map between these things.
     3. Many environments use non-routable IP addresses, such as the
        10. network.
     For these and other reasons, various types of firewalls and proxies
     will be deployed for iSCSI, similar in nature to those already
     handling protocols such as HTTP and FTP.
   1. Port Redirector
     A port redirector is a stateless device that is not aware of iSCSI.
     It is used to do Network Address Translation (NAT), which can map
   IP addresses between routable and non-routable domains, as well as
   map TCP ports.  While devices providing these capabilities can often
     filter based on IP addresses and TCP ports, they generally do not
     provide meaningful security, and are used instead to resolve
   internal network routing issues.
     Since it is entirely possible that these devices are used as
     routers and/or aggregators between a firewall and an iSCSI
     initiator or target, iSCSI connections must be operable through
     Effects on iSCSI:
     - iSCSI-level data integrity checks must not include information
       from the TCP or IP headers, as these may be changed in between
       the initiator and target.
     - iSCSI messages that specify a particular initiator or target,
       such as login requests and third party requests, should specify
       the initiator or target in a location-independent manner.
       This is accomplished using the WWUI.
   Voruganti iSCSI Naming and Discovery - Expires August 2001       33
   2. SOCKS server
     A SOCKS server can be used to map TCP connections from one network
     domain to another.  It is aware of the state of each TCP
     The SOCKS server provides authenticated firewall traversal for
     applications that are not firewall-aware.  Conceptually, SOCKS is
     a "shim-layer" that exists between the application (i.e., iSCSI)
     and TCP.
     To use SOCKS, the iSCSI initiator must be modified to use the
     encapsulation routines in the SOCKS library.  The initiator
     the opens up a TCP connection to the SOCKS server, typically on
     the canonical SOCKS port 1080.  A subnegotiation then occurs,
     during which the initiator is either authenticated or denied
     the connection request.  If authenticated, the SOCKS server then
     opens a TCP connection to the iSCSI target using addressing
     information sent to it by the initiator in the SOCKS shim.  The
     SOCKS server then forwards iSCSI commands, data, and responses
     between the iSCSI initiator and target.
     Use of the SOCKS server requires special modifications to the
     iSCSI initiator.  No modifications are required to the iSCSI
     As a SOCKS server can map most of the addresses and information
     contained within the IP and TCP headers, including sequence
   numbers, its effects on iSCSI are identical to those in the port
   3. iSCSI Proxy
     An iSCSI proxy is similar to proxies available in HTTP.
     The initiator is aware of the actual addresses of the targets,
     but instead of connecting to the addresses, connects instead
     to a proxy's address.  The proxy, in turn, connects to the
     actual targets.  This is similar to the HTTP/1.1 proxy, where
     the client passes the entire URL (including IP and TCP address)
     to the proxy, rather than just the path name.
     An iSCSI proxy can provide some good iSCSI-level access
     control and other functionality, while adding fairly light
     configuration responsibilities.
     Effects on iSCSI:
     - When logging in to a target at a proxy address instead of the
       actual address, the target should include the TargetAddress (IP
       address and TCP port) of the target, in addition to its WWUI.
   Note, however, that this directly conflicts with the statement made
       regarding NAT firewalls.  Since the WWUI is enough to uniquely
   Voruganti iSCSI Naming and Discovery - Expires August 2001       34
       identify an iSCSI device, the TargetAddress must then be used by
   the proxy as a hint on where to find the WWUI, and not as the final
     - This is beginning to be covered in the iSCSI specification.
     Having the address passed with the WWUI would allow an iSCSI
     proxy to exist without extra configuration or name services.
     Using this type of proxy can eliminate the need to implement SOCKS.
   4. SCSI gateway
     This gateway presents logical targets (WWUIs) to the initiators,
   and maps them to real iSCSI targets as it chooses.  The initiator
   sees this gateway as a real iSCSI target, and is unaware of any proxy
   or gateway behavior.  The gateway may manufacture its own WWUIs, or
   use those provided by the real devices.  This type of gateway is used
   to represent parallel SCSI, Fibre Channel, SSA, or other devices as
   iSCSI devices.
     Nearly any capability that could be imagined is possible with this
     type of gateway, but it may require more configuration than an
     iSCSI proxy.
     Effects on iSCSI:
     - Since the initiator is unaware of any addresses beyond the
       gateway, the gateway's own address is for all practial
       purposes the real address of a target.  Only the WWUI needs
       to be passed.  This is already done in iSCSI, so there are
       no further requirements to support SCSI gateways.
   5. Stateful Inspection Firewall (stealth iSCSI firewall)
      The Stealth model would exist as an iSCSI-aware firewall, that
      is invisible to the initiator, but provides capabilities found
      in the iSCSI proxy.
      Effects on iSCSI:
      - Since this is invisible, I don't think there are any
        additional requirements on the iSCSI protocol for this
      This one is more difficult in some ways to implement, simply
      because it has to be part of a standard firewall product,
      rather than part of an iSCSI-type product.  For this reason,
      I would not expect to see these implemented for a while.
      Also note that this type of firewall is only effective
      in the outbound direction (allowing an initiator behind the
   Voruganti iSCSI Naming and Discovery - Expires August 2001       35
      February 2001
      firewall to connect to an outside target), unless the iSCSI target
   is located in a DMZ.  It does not provide adequate security
            8. References
   [1] Edwards, K., "Core Jini: In Depth: Discovery", Prentice Hall,
   [2] John, R., "UPnP, Jini and Salutation- A look at some popular
   coordination frameworks for future networked devices",
   http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999.
   [3] http://www.srvloc.org
   [4] Freed, N., "Behavior of and Requirements for Internet Firewalls",
            RFC 2979, October 2000.
   [5] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and
            Metropolitan Area Networks: Overview and Architecture
   [6] Kessler, G. and Shepard, S., "A Primer On Internet and TCP/IP
   and Utilities", RFC 2151, June 1997.
   [7] Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P.,
   Haagens, R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI",
   draft-ietf-ips-iscsi-00.txt, February, 2000.
   [8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage Name
   Service", draft-tseng-ips-isns-00.txt, October 2000.
   [9] RFC 1737, "Functional Requirements for Uniform Resource Names".
   [10] RFC 1035, "Domain Names - Implementation and Specification".
   OUI - "IEEE OUI and Company_Id Assignments",
   [11]EUI - "Guidelines for 64-bit Global Identifier (EUI-64)
    Registration Authority
   [12] RFC 2396, "Uniform Resource Identifiers".
   [13] RFC 2276, "Architectural Principles of URN Resolution".
   [14] RFC 2483, "URI Resolution Services".
   Voruganti iSCSI Naming and Discovery - Expires August 2001       36
   [15] RFC 2141, "URN Syntax".
   [16] RFC 2611, "URN Namespace Definition Mechanisms".
   [17] RFC 2608, SLP Version 2.
   [18] RFC 2610, DHCP Options for the Service Location Protocol.
   [19] P. Sarkar et al, "A Standard for Bootstrapping Clients using the
   iSCSI Protocol", draft-ietf-ips-iscsi-boot-01.
   [20] M. Bakke et al, "A URN Namespace for iSCSI World-Wide Unique
   Identifiers", draft-bakke-iscsi-wwui-urn-00 February 2001.
   [21] M. Bakke et al,ÆÆFinding iSCSI Targets and Name Servers using
   SLPÆÆ, draft-bakke-iscsi-SLP-template.00.
            6. Contact Author
            Kaladhar Voruganti
            650 Harry Road
            IBM Almaden Research
            San Jose, CA
            Email: kaladhar@us.ibm.com
            Voruganti            Internet Draft Expires August 2001
         iSCSI Naming and Discovery        February 2001
   "Copyright (C) The Internet Society (date). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others,  and derivative works that comment on or otherwise explain it
   or assist  in its implementation may be prepared, copied, published
   and distributed,in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, Full Copyright
   Statement such as by removing the copyright notice or references to
   the Internet Society or other Internet organizations, except as
   needed for the purpose of developing Internet standards in which case
   the procedures for copyrights defined in the Internet Standards
   process must be followed, or as required to translate it into
   languages other than  English.
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   Voruganti iSCSI Naming and Discovery - Expires August 2001       37
            Expires August 2001
     Voruganti  iSCSI Naming and Discovery Draft Expires August 2001
   Voruganti iSCSI Naming and Discovery - Expires August 2001       38

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/