rfc3721.txt

一个学习iSCSI协议的文档

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