doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc3721.txt b/doc/rfc/rfc3721.txt
new file mode 100644
index 0000000..0ca15d0
--- /dev/null
+++ b/doc/rfc/rfc3721.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                           M. Bakke
+Request for Comments: 3721                                         Cisco
+Category: Informational                                        J. Hafner
+                                                              J. Hufferd
+                                                            K. Voruganti
+                                                                     IBM
+                                                              M. Krueger
+                                                         Hewlett-Packard
+                                                              April 2004
+
+
+           Internet Small Computer Systems Interface (iSCSI)
+                          Naming and Discovery
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document provides examples of the Internet Small Computer
+   Systems Interface (iSCSI; or SCSI over TCP) name construction and
+   discussion of discovery of iSCSI resources (targets) by iSCSI
+   initiators.  This document complements the iSCSI protocol document.
+   Flexibility is the key guiding principle behind this document.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke, et al.                Informational                      [Page 1]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+Table of Contents
+
+   1. iSCSI Names and Addresses. . . . . . . . . . . . . . . . . . .   3
+      1.1.  Constructing iSCSI names using the iqn. format . . . . .   5
+      1.2.  Constructing iSCSI names using the eui. format . . . . .   8
+   2. iSCSI Alias. . . . . . . . . . . . . . . . . . . . . . . . . .   8
+      2.1.  Purpose of an Alias. . . . . . . . . . . . . . . . . . .   8
+      2.2.  Target Alias . . . . . . . . . . . . . . . . . . . . . .   9
+      2.3.  Initiator Alias. . . . . . . . . . . . . . . . . . . . .  10
+   3. iSCSI Discovery. . . . . . . . . . . . . . . . . . . . . . . .  12
+   4. Security Considerations. . . . . . . . . . . . . . . . . . . .  13
+   5. References . . . . . . . . . . . . . . . . . . . . . . . . . .  13
+      5.1.  Normative References . . . . . . . . . . . . . . . . . .  13
+      5.2.  Informative References . . . . . . . . . . . . . . . . .  14
+   6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  14
+   Appendix A: iSCSI Naming Notes. . . . . . . . . . . . . . . . . .  15
+   Appendix B: Interaction with Proxies and Firewalls. . . . . . . .  16
+               B.1.  Port Redirector . . . . . . . . . . . . . . . .  16
+               B.2.  SOCKS server. . . . . . . . . . . . . . . . . .  17
+               B.3.  SCSI gateway. . . . . . . . . . . . . . . . . .  17
+               B.4.  iSCSI Proxy . . . . . . . . . . . . . . . . . .  18
+               B.5.  Stateful Inspection Firewall. . . . . . . . . .  18
+   Appendix C: iSCSI Names and Security Identifiers. . . . . . . . .  19
+   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .  21
+   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke, et al.                Informational                      [Page 2]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+1.  iSCSI Names and Addresses
+
+   The main addressable, discoverable entity in iSCSI is an iSCSI Node.
+   An iSCSI node can be either an initiator, a target, or both.  The
+   rules for constructing an iSCSI name are specified in [RFC3720].
+
+   This document provides examples of name construction that might be
+   used by a naming authority.
+
+   Both targets and initiators require names for the purpose of
+   identification, so that iSCSI storage resources can be managed
+   regardless of location (address).  An iSCSI name is the unique
+   identifier for an iSCSI node, and is also the SCSI device name [SAM2]
+   of an iSCSI device.  The iSCSI name is the principal object used in
+   authentication of targets to initiators and initiators to targets.
+   This name is also used to identify and manage iSCSI storage
+   resources.
+
+   Furthermore, iSCSI names are associated with iSCSI nodes instead of
+   with network adapter cards to ensure the free movement of network
+   HBAs between hosts without loss of SCSI state information
+   (reservations, mode page settings etc) and authorization
+   configuration.
+
+   An iSCSI node also has one or more addresses.  An iSCSI address
+   specifies a single path to an iSCSI node and consists of the iSCSI
+   name, plus a transport (TCP) address which uses the following format:
+
+      <domain-name>[:<port>]
+
+   Where <domain-name> is one of:
+
+   -  IPv4 address, in dotted decimal notation.  Assumed if the name
+      contains exactly four numbers, separated by dots (.), where each
+      number is in the range 0..255.
+
+   -  IPv6 address, in colon-separated hexadecimal notation, as
+      specified in [RFC3513] and enclosed in "[" and "]" characters, as
+      specified in [RFC2732].
+
+   -  Fully Qualified Domain Name (host name).  Assumed if the <domain-
+      name> is neither an IPv4 nor an IPv6 address.
+
+   For iSCSI targets, the <port> in the address is optional; if
+   specified, it is the TCP port on which the target is listening for
+   connections.  If the <port> is not specified, the default port 3260,
+   assigned by IANA, will be assumed.  For iSCSI initiators, the <port>
+   is omitted.
+
+
+
+Bakke, et al.                Informational                      [Page 3]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   Examples of addresses:
+
+   192.0.2.2
+   192.0.2.23:5003
+   [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]
+   [1080:0:0:0:8:800:200C:417A]
+   [3ffe:2a00:100:7031::1]
+   [1080::8:800:200C:417A]
+   [1080::8:800:200C:417A]:3260
+   [::192.0.2.5]
+   mydisks.example.com
+   moredisks.example.com:5003
+
+   The concepts of names and addresses have been carefully separated in
+   iSCSI:
+
+   -  An iSCSI Name is a location-independent, permanent identifier for
+      an iSCSI node.  An iSCSI node has one iSCSI name, which stays
+      constant for the life of the node.  The terms "initiator name" and
+      "target name" also refer to an iSCSI name.
+
+   -  An iSCSI Address specifies not only the iSCSI name of an iSCSI
+      node, but also a location of that node.  The address consists of a
+      host name or IP address, a TCP port number (for the target), and
+      the iSCSI Name of the node.  An iSCSI node can have any number of
+      addresses, which can change at any time, particularly if they are
+      assigned via DHCP.
+
+   A similar analogy exists for people.  A person in the USA might be:
+
+      Robert Smith
+      SSN+DateOfBirth: 333-44-5555 14-MAR-1960
+      Phone: +1 (763) 555.1212
+      Home Address: 555 Big Road, Minneapolis, MN 55444
+      Work Address: 222 Freeway Blvd, St. Paul, MN 55333
+
+   In this case, Robert's globally unique name is really his Social
+   Security Number plus Date of Birth.  His common name, "Robert Smith",
+   is not guaranteed to be unique.  Robert has three locations at which
+   he may be reached; two Physical addresses, and a phone number.
+
+   In this example, Robert's SSN+DOB is like the iSCSI Name (date of
+   birth is required to disambiguate SSNs that have been reused), his
+   phone number and addresses are analogous to an iSCSI node's TCP
+   addresses, and "Robert Smith" would be a human-friendly label for
+   this person.
+
+
+
+
+
+Bakke, et al.                Informational                      [Page 4]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   To assist in providing a more human-readable user interface for
+   devices that contain iSCSI targets and initiators, a target or
+   initiator may also provide an alias.  This alias is a simple UTF-8
+   string, is not globally unique, and is never interpreted or used to
+   identify an initiator or device within the iSCSI protocol.  Its use
+   is described further in section 2.
+
+1.1.  Constructing iSCSI names using the iqn. format
+
+   The iSCSI naming scheme was constructed to give an organizational
+   naming authority the flexibility to further subdivide the
+   responsibility for name creation to subordinate naming authorities.
+   The iSCSI qualified name format is defined in [RFC3720] and contains
+   (in order):
+
+   -  The string "iqn."
+
+   -  A date code specifying the year and month in which the
+      organization registered the domain or sub-domain name used as the
+      naming authority string.
+
+   -  The organizational naming authority string, which consists of a
+      valid, reversed domain or subdomain name.
+
+   -  Optionally, a ':', followed by a string of the assigning
+      organization's choosing, which must make each assigned iSCSI name
+      unique.
+
+   The following is an example of an iSCSI qualified name from an
+   equipment vendor:
+
+        Organizational      Subgroup Naming Authority
+                Naming      and/or string Defined by
+   Type  Date     Auth      Org. or Local Naming Authority
+   +--++-----+ +---------+ +--------------------------------+
+   |  ||     | |         | |                                |
+
+   iqn.2001-04.com.example:diskarrays-sn-a8675309
+
+   Where:
+
+      "iqn" specifies the use of the iSCSI qualified name as the
+      authority.
+
+
+
+
+
+
+
+
+Bakke, et al.                Informational                      [Page 5]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+      "2001-04" is the year and month on which the naming authority
+      acquired the domain name used in this iSCSI name.  This is used to
+      ensure that when domain names are sold or transferred to another
+      organization, iSCSI names generated by these organizations will be
+      unique.
+
+      "com.example" is a reversed DNS name, and defines the
+      organizational naming authority.  The owner of the DNS name
+      "example.com" has the sole right of use of this name as this part
+      of an iSCSI name, as well as the responsibility to keep the
+      remainder of the iSCSI name unique.  In this case, example.com
+      happens to manufacture disk arrays.
+
+      "diskarrays" was picked arbitrarily by example.com to identify the
+      disk arrays they manufacture.  Another product that ACME makes
+      might use a different name, and have its own namespace independent
+      of the disk array group.  The owner of "example.com" is
+      responsible for keeping this structure unique.
+
+      "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
+      iSCSI Names 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.
+
+      Another example shows how the ':' separator helps owners of sub-
+      domains to keep their name spaces unique:
+
+                  Naming            Defined by
+   Type  Date     Authority         Naming Authority
+   +--++-----+ +-----------------+ +-----------+
+   |  ||     | |                 | |           |
+
+   iqn.2001-04.com.example.storage:tape.sys1.xyz
+
+                  Naming                Defined by
+   Type  Date     Authority             Naming Authority
+   +--++-----+ +----------------------+ +-----------+
+   |  ||     | |                      | |           |
+
+   iqn.2001-04.com.example.storage.tape:sys1.xyz
+
+
+
+
+
+
+
+Bakke, et al.                Informational                      [Page 6]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   Note that, except for the ':' separator, both names are identical.
+   The first was assigned by the owner of the subdomain
+   "storage.example.com"; the second was assigned by the owner of
+   "tape.storage.example.com".  These are both legal names, and are
+   unique.
+
+   The following is an example of a name that might be constructed by a
+   research organization:
+
+                Naming        Defined by  Defined by
+   Type  Date    Authority      cs dept    User "oaks"
+    +-+ +-----+ +------------+ +--------+ +-----------+
+    | | |     | |            | |        | |           |
+    iqn.2000-02.edu.example.cs:users.oaks:proto.target4
+
+   In the above example, Professor Oaks of Example University is
+   building research prototypes of iSCSI targets.  EU's computer science
+   department allows each user to use his or her user name as a naming
+   authority for this type of work, by attaching "users.<username>"
+   after the ':', and another ':', followed by a string of the user's
+   choosing (the user is responsible for making this part unique).
+   Professor Oaks chose to use "proto.target4" for this particular
+   target.
+
+   The following is an example of an iSCSI name string from a storage
+   service provider:
+
+                Organization            String
+                   Naming            Defined by Org.
+   Type  Date    Authority          Naming Authority
+    +-+ +-----+ +-------------+ +----------------------+
+    | | |     | |             | |                      |
+    iqn.1995-11.com.example.ssp:customers.4567.disks.107
+
+   In this case, a storage service provider (ssp.example.com) has
+   decided to re-name the targets from the manufacturer, to provide the
+   flexibility to move the customer's data to a different storage
+   subsystem should the need arise.
+
+   The Storage Service Provider (SSP) has configured the iSCSI Name on
+   this particular target for one of its customers, and has determined
+   that it made the most sense to track these targets by their Customer
+   ID number and a disk number.  This target was created for use by
+   customer #4567, and is the 107th target configured for this customer.
+
+   Note that when reversing these domain names, the first component
+   (after the "iqn.") will always be a top-level domain name, which
+   includes "com", "edu", "gov", "org", "net", "mil", or one of the
+
+
+
+Bakke, et al.                Informational                      [Page 7]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   two-letter country codes.  The use of anything else as the first
+   component of these names is not allowed.  In particular, companies
+   generating these names must not eliminate their "com." from the
+   string.
+
+   Again, these iSCSI names are NOT addresses.  Even though they make
+   use of DNS domain names, they are used only to specify the naming
+   authority.  An iSCSI name contains no implications of the iSCSI
+   target or initiator's location.  The use of the domain name is only a
+   method of re-using an already ubiquitous name space.
+
+1.2.  Constructing iSCSI names using the eui. format
+
+   The iSCSI eui. naming format allows a naming authority to use IEEE
+   EUI-64 identifiers in constructing iSCSI names.  The details of
+   constructing EUI-64 identifiers are specified by the IEEE
+   Registration Authority (see [EUI64]).
+
+      Example iSCSI name:
+
+      Type  EUI-64 identifier (ASCII-encoded hexadecimal)
+      +--++--------------+
+      |  ||              |
+      eui.02004567A425678D
+
+2.  iSCSI Alias
+
+   The iSCSI alias 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 requirements of the iSCSI
+   name.  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.
+
+   The alias is a variable length string, between 0 and 255 characters,
+   and is terminated with at least one NULL (0x00) character, as defined
+   in [RFC3720].  No other structure is imposed upon this string.
+
+2.1.  Purpose of an Alias
+
+   Initiators and targets are uniquely identified by an iSCSI Name.
+   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 to be
+   assigned from a point of view different from that of the other side
+
+
+
+Bakke, et al.                Informational                      [Page 8]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   of the connection.  For instance, a target name 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 name, 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.
+
+   Both targets and initiators may have aliases.
+
+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 Target Name for the new target, and probably an
+   address, back to the user.  The user then adds this Target Name 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 management "show targets" button to show the targets to which
+   the host is currently connected.
+
+   +--Connected-To-These-Targets----------------------
+   |
+   |  Target Name
+   |
+   |  iqn.1995-04.com.example:sn.5551212.target.450
+   |  iqn.1995-04.com.example:sn.5551212.target.489
+   |  iqn.1995-04.com.example:sn.8675309
+   |  iqn.2001-04.com.example.storage:tape.sys1.xyz
+   |  iqn.2001-04.com.example.storage.tape:sys1.xyz
+   |
+   +--------------------------------------------------
+
+
+
+
+
+
+Bakke, et al.                Informational                      [Page 9]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   In the above example, the user sees a collection of iSCSI Names, 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 storage administrator configures an alias for each target name,
+   the alias can provide a more descriptive name.  This alias may be
+   sent back to the initiator as part of the login response, or found in
+   the iSCSI MIB.  It then might be used in a display such as the
+   following:
+
+   +--Connected-To-These-Targets----------------------
+   |
+   |  Alias          Target Name
+   |
+   |  Oracle 1       iqn.1995-04.com.example:sn.5551212.target.450
+   |  Local Disk     iqn.1995-04.com.example:sn.5551212.target.489
+   |  Exchange 2     iqn.1995-04.com.example: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 if seen in the login
+   response.
+
+2.3.  Initiator Alias
+
+   An initiator alias can be used in the same manner as a target alias.
+   An initiator may send the alias in a login request, when it sends its
+   iSCSI Initiator Name.  The alias is not used for authentication, but
+   may be kept with the session information for display through a
+   management Graphical User Interface (GUI) or command-line interface
+   (for a more complex subsystem or gateway), or through the iSCSI MIB.
+
+   Note that a simple target can just ignore the Initiator Alias if it
+   has no management interface on which to display it.
+
+
+
+
+Bakke, et al.                Informational                     [Page 10]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   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 of a management interface showing a list of
+   sessions on an iSCSI target network entity.  For this display, the
+   targets are using an internal target number, which is a fictional
+   field that has purely internal significance.
+
+   +--Connected-To-These-Initiators-------------------
+   |
+   |  Target   Initiator Name
+   |
+   |  450      iqn.1995-04.com.example.sw:cd.12345678-OEM-456
+   |  451      iqn.1995-04.com.example.os:hostid.A598B45C
+   |  309      iqn.1995-04.com.example.sw:cd.87654321-OEM-259
+   |
+   +--------------------------------------------------
+
+   And with the initiator alias displayed:
+
+   +--Connected-To-These-Initiators-------------------
+   |
+   |  Target Alias               Initiator Name
+   |
+   |  450    Web Server 4        iqn.1995-04.com.example.sw:cd.12...
+   |  451    scsigw.example.com  iqn.1995-04.com.example.os:hosti...
+   |  309    Exchange Server     iqn.1995-04.com.example.sw:cd.87...
+   |
+   +--------------------------------------------------
+
+   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 and require a
+   management application.
+
+   Aliases are extremely easy to implement.  Targets just send a
+   TargetAlias whenever they send a TargetName.  Initiators just send an
+   InitiatorAlias whenever they send an InitiatorName.  If an alias is
+   received that does not fit, or seems invalid in any way, it is
+   ignored.
+
+
+
+Bakke, et al.                Informational                     [Page 11]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+3.  iSCSI Discovery
+
+   The goal of iSCSI discovery is to allow an initiator to find the
+   targets to which it has access, 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.  Moreover, the iSCSI discovery
+   mechanisms listed here only deal with target discovery and one still
+   needs to use the SCSI protocol for LUN discovery.
+
+   In order for an iSCSI initiator to establish an iSCSI session with an
+   iSCSI target, the initiator needs the IP address, TCP port number and
+   iSCSI target name information.  The goal of iSCSI discovery
+   mechanisms are to provide low overhead support for small iSCSI
+   setups, and scalable discovery solutions for large enterprise setups.
+   Thus, there are several methods that may be used to find targets
+   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
+   dynamically.  The various discovery mechanisms differ in their
+   assumptions about what information is already available to the
+   initiators and what information needs to be still discovered.
+
+   iSCSI supports the following discovery mechanisms:
+
+   a. Static Configuration: This mechanism assumes that the IP address,
+      TCP port and the iSCSI target name information are already
+      available to the initiator.  The initiators need to perform no
+      discovery in this approach.  The initiator uses the IP address and
+      the TCP port information to establish a TCP connection, and it
+      uses the iSCSI target name information to establish an iSCSI
+      session.  This discovery option is convenient for small iSCSI
+      setups.
+
+   b. SendTargets: This mechanism assumes that the target's IP address
+      and TCP port information are already available to the initiator.
+      The initiator then uses this information to establish a discovery
+      session to the Network Entity.  The initiator then subsequently
+      issues the SendTargets text command to query information about the
+      iSCSI targets available at the particular Network Entity (IP
+      address).  SendTargets command details can be found in the iSCSI
+      document [RFC3720].  This discovery option is convenient for iSCSI
+      gateways and routers.
+
+   c. Zero-Configuration: This mechanism assumes that the initiator does
+      not have any information about the target.  In this option, the
+      initiator can either multicast discovery messages directly to the
+
+
+
+Bakke, et al.                Informational                     [Page 12]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+      targets or it can send discovery messages to storage name servers.
+      Currently, there are many general purpose discovery frameworks
+      available such as Salutation [John], Jini [John], UPnP [John], SLP
+      [RFC2608] and iSNS [iSNS].  However, with respect to iSCSI, SLP
+      can clearly perform the needed discovery functions [iSCSI-SLP],
+      while iSNS [iSNS] can be used to provide related management
+      functions including notification, access management,
+      configuration, and discovery management.  iSCSI equipment that
+      need discovery functions beyond SendTargets should at least
+      implement SLP, and then consider iSNS when extended discovery
+      management capabilities are required such as in larger storage
+      networks.  It should be noted that since iSNS will support SLP,
+      iSNS can be used to help manage the discovery information returned
+      by SLP.
+
+4.  Security Considerations
+
+   Most security issues relating to iSCSI naming are discussed in the
+   main iSCSI document [RFC3720] and the iSCSI security document
+   [RFC3723].
+
+   In addition, Appendix B discusses naming and discovery issues when
+   gateways, proxies, and firewalls are used to solve security or
+   discovery issues in some situations where iSCSI is deployed.
+
+   iSCSI allows several different authentication methods to be used.
+   For many of these methods, an authentication identifier is used,
+   which may be different from the iSCSI node name of the entity being
+   authenticated.  This is discussed in more detail in Appendix C.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC3720]   Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and
+               E. Zeidner, "Internet Small Computer Systems Interface
+               (iSCSI)", RFC 3720, April 2004.
+
+   [EUI64]     EUI - "Guidelines for 64-bit Global Identifier (EUI-64)
+               Registration Authority,
+               http://standards.ieee.org/regauth/oui/tutorials/
+               EUI64.html
+
+   [SAM2]      R. Weber et al, INCITS T10 Project 1157-D revision 24,
+               "SCSI Architectural Model - 2 (SAM-2)", Section 4.7.6
+               "SCSI device name", September 2002.
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 13]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+5.2.  Informative References
+
+   [RFC2608]   Guttman, E., Perkins, C., Veizades, J. and M. Day, "SLP
+               Version 2", RFC 2608, June 1999.
+
+   [RFC2732]   Hinden, R., Carpenter, B. and L. Masinter, "Format for
+               Literal IPv6 Addresses in URL's", RFC 2732, December
+               1999.
+
+   [RFC2979]   Freed, N., "Behavior of and Requirements for Internet
+               Firewalls", RFC 2979, October 2000.
+
+   [RFC3303]   Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and
+               A. Rayhan, "Middlebox Communication Architecture and
+               Framework", RFC 3303, August 2002.
+
+   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6
+               Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3723]   Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
+               Travostino, "Securing Block Storage Protocols over IP",
+               RFC 3723, April 2004.
+
+   [iSCSI-SLP] Bakke, M., et al., "Finding iSCSI Targets and Name
+               Servers using SLP", Work in Progress, March 2003.
+
+   [iSNS]      Tseng, J., et al., "Internet Storage Name Service
+               (iSNS)", Work in Progress, January 2003.
+
+   [John]      R. John, "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.
+
+6. Acknowledgements
+
+   Joe Czap (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein
+   (SANRAD), Larry Lamers (Adaptec), Josh Tseng (Nishan Systems), and
+   Todd Sperry (Adaptec) have participated and made contributions during
+   development of this document.
+
+
+
+
+
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 14]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+Appendix A: iSCSI Naming Notes
+
+   Some iSCSI Name Examples for Targets
+
+   -  Assign to a target based on controller serial number
+
+      iqn.2001-04.com.example:diskarray.sn.8675309
+
+   -  Assign to a target based on serial number
+
+      iqn.2001-04.com.example:diskarray.sn.8675309.oracle-db-1
+
+   Where oracle-db-1 might be a target label 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 iSCSI Name should never be assigned based on interface
+   hardware, or other hardware that can be swapped and moved to other
+   devices.
+
+   Some iSCSI Name Examples for Initiators
+
+   -  Assign to the OS image by fully qualified host name
+
+      iqn.2001-04.com.example.os:dns.com.customer1.host-four
+
+   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 iSCSI Name.
+
+   - Assign to the OS image by OS install serial number
+
+      iqn.2001-04.com.example.os:newos5.12345-OEM-0067890-23456
+
+   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 Raid Array by a service provider
+
+      iqn.2001-04.com.example.myssp:users.mbakke05657
+
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 15]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+Appendix B: Interaction with Proxies and Firewalls
+
+   iSCSI has been designed to allow SCSI initiators and targets to
+   communicate over an arbitrary IP network.  This means that in theory,
+   making some assumptions about authentication and security, the whole
+   internet could be used as one giant storage network.
+
+   However, there are many access and scaling problems that would come
+   up when this is attempted.
+
+   1. Most iSCSI targets may only be meant to be accessed by one or a
+      few initiators.  Discovering everything would be unnecessary.
+
+   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 [RFC2979] and
+   proxies will be deployed for iSCSI, similar in nature to those
+   already handling protocols such as HTTP and FTP.
+
+B.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 them.
+
+   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.
+
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 16]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   -  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 iSCSI Name.
+
+   -  When an iSCSI discovery connection is to be used through a port
+      redirector, a target will have to be configured to return a domain
+      name instead of an IP address in a SendTargets response, since the
+      port redirector will not be able to map the IP address(es)
+      returned in the iSCSI message.  It is a good practice to do this
+      anyway.
+
+B.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 connection.
+
+   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 then
+   opens up a TCP connection to the SOCKS server, typically on the
+   canonical SOCKS port 1080.  A sub-negotiation 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 target.
+
+   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 redirector.
+
+B.3. SCSI gateway
+
+   This gateway presents logical targets (iSCSI Names) to the
+   initiators, and maps them to SCSI 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
+   iSCSI Names, or map the iSCSI names using information provided by the
+   physical SCSI devices.  It is the responsibility of the gateway to
+
+
+
+Bakke, et al.                Informational                     [Page 17]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   ensure the uniqueness of any iSCSI name it manufactures.  The gateway
+   may have to account for multiple gateways having access to a single
+   physical device.  This type of gateway is used to present parallel
+   SCSI, Fibre Channel, SSA, or other devices as iSCSI devices.
+
+   Effects on iSCSI:
+
+   -  Since the initiator is unaware of any addresses beyond the
+      gateway, the gateway's own address is for all practical purposes
+      the real address of a target.  Only the iSCSI Name needs to be
+      passed.  This is already done in iSCSI, so there are no further
+      requirements to support SCSI gateways.
+
+B.4. iSCSI Proxy
+
+   An iSCSI proxy is a gateway that terminates the iSCSI protocol on
+   both sides, rather than translate between iSCSI and some other
+   transport.  The proxy functionality is aware that both sides are
+   iSCSI, and can take advantage of optimizations, such as the
+   preservation of data integrity checks.  Since an iSCSI initiator's
+   discovery or configuration of a set of targets makes use of address-
+   independent iSCSI names, iSCSI does not have the same proxy
+   addressing problems as HTTP, which includes address information into
+   its URLs.  If a proxy is to provide services to an initiator on
+   behalf of a target, the proxy allows the initiator to discover its
+   address for the target, and the actual target device is discovered
+   only by the proxy.  Neither the initiator nor the iSCSI protocol
+   needs to be aware of the existence of the proxy.  Note that a SCSI
+   gateway may also provide iSCSI proxy functionality when mapping
+   targets between two iSCSI interfaces.
+
+   Effects on iSCSI:
+
+   -  Same as a SCSI gateway.  The only other effect is that iSCSI must
+      separate data integrity checking on iSCSI headers and iSCSI data,
+      to allow the data integrity check on the data to be propagated
+      end-to-end through the proxy.
+
+B.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, there are no additional requirements on
+      the iSCSI protocol for this one.
+
+
+
+Bakke, et al.                Informational                     [Page 18]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   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.
+
+   Also note that this type of firewall is only effective in the
+   outbound direction (allowing an initiator behind the firewall to
+   connect to an outside target), unless the iSCSI target is located in
+   a DMZ (De-Militarized Zone) [RFC3303].  It does not provide adequate
+   security otherwise.
+
+Appendix C: iSCSI Names and Security Identifiers
+
+   This document has described the creation and use of iSCSI Node Names.
+   There will be trusted environments where this is a sufficient form of
+   identification.  In these environments the iSCSI Target may have an
+   Access Control List (ACL), which will contain a list of authorized
+   entities that are permitted to access a restricted resource (in this
+   case a Target Storage Controller).  The iSCSI Target will then use
+   that ACL to permit (or not) certain iSCSI Initiators to access the
+   storage at the iSCSI Target Node.  This form of ACL is used to
+   prevent trusted initiators from making a mistake and connecting to
+   the wrong storage controller.
+
+   It is also possible that the ACL and the iSCSI Initiator Node Name
+   can be used in conjunction with the SCSI layer for the appropriate
+   SCSI association of LUNs with the Initiator.  The SCSI layer's use of
+   the ACL will not be discussed further in this document.
+
+   There will be situations where the iSCSI Nodes exist in untrusted
+   environments.  That is, some iSCSI Initiator Nodes may be authorized
+   to access an iSCSI Target Node, however, because of the untrusted
+   environment, nodes on the network cannot be trusted to give the
+   correct iSCSI Initiator Node Names.
+
+   In untrusted environments an additional type of identification is
+   required to assure the target that it really knows the identity of
+   the requesting entity.
+
+   The authentication and authorization in the iSCSI layer is
+   independent of anything that IPSec might handle, underneath or around
+   the TCP layer.  This means that the initiator node needs to pass some
+   type of security related identification information (e.g., userid) to
+   a security authentication process such as SRP, CHAP, Kerberos etc.
+   (These authentication processes will not be discussed in this
+   document.)
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 19]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+   Upon the completion of the iSCSI security authentication, the
+   installation knows "who" sent the request for access.  The
+   installation must then check to ensure that such a request, from the
+   identified entity, is permitted/authorized.  This form of
+   Authorization is generally accomplished via an Access Control List
+   (ACL) as described above.  Using this authorization process, the
+   iSCSI target will know that the entity is authorized to access the
+   iSCSI Target Node.
+
+   It may be possible for an installation to set a rule that the
+   security identification information (e.g., UserID) be equal to the
+   iSCSI Initiator Node Name.  In that case, the ACL approach described
+   above should be all the authorization that is needed.
+
+   If, however, the iSCSI Initiator Node Name is not used as the
+   security identifier there is a need for more elaborate ACL
+   functionality.  This means that the target requires a mechanism to
+   map the security identifier (e.g., UserID) information to the iSCSI
+   Initiator Node Name.  That is, the target must be sure that the
+   entity requesting access is authorized to use the name, which was
+   specified with the Login Keyword "InitiatorName=".  For example, if
+   security identifier 'Frank' is authorized to access the target via
+   iSCSI InitiatorName=xxxx, but 'Frank' tries to access the target via
+   iSCSI InitiatorName=yyyy, then this login should be rejected.
+
+   On the other hand, it is possible that 'Frank' is a roaming user (or
+   a Storage Administrator) that "owns" several different systems, and
+   thus, could be authorized to access the target via multiple different
+   iSCSI initiators.  In this case, the ACL needs to have the names of
+   all the initiators through which 'Frank' can access the target.
+
+   There may be other more elaborate ACL approaches, which can also be
+   deployed to provide the installation/user with even more security
+   with flexibility.
+
+   The above discussion is trying to inform the reader that, not only is
+   there a need for access control dealing with iSCSI Initiator Node
+   Names, but in certain iSCSI environments there might also be a need
+   for other complementary security identifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 20]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+Authors' Addresses
+
+   Kaladhar Voruganti
+   IBM Almaden Research Center
+   650 Harry Road
+   San Jose, CA 95120
+
+   EMail: kaladhar@us.ibm.com
+
+
+   Mark Bakke
+   Cisco Systems, Inc.
+   6450 Wedgwood Road
+   Maple Grove, MN 55311
+
+   Phone: +1 763 398-1054
+   EMail: mbakke@cisco.com
+
+
+   Jim Hafner
+   IBM Almaden Research Center
+   650 Harry Road
+   San Jose, CA 95120
+
+   Phone: +1 408 927-1892
+   EMail: hafner@almaden.ibm.com
+
+
+   John L. Hufferd
+   IBM Storage Systems Group
+   5600 Cottle Road
+   San Jose, CA 95193
+
+   Phone: +1 408 256-0403
+   EMail: hufferd@us.ibm.com
+
+
+   Marjorie Krueger
+   Hewlett-Packard Corporation
+   8000 Foothills Blvd
+   Roseville, CA 95747-5668, USA
+
+   Phone: +1 916 785-2656
+   EMail: marjorie_krueger@hp.com
+
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 21]
+
+RFC 3721               iSCSI Naming and Discovery             April 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Bakke, et al.                Informational                     [Page 22]
+