iSCSI Naming: iqn format specification

[Mark Bakke <mbakke@cisco.com>]

During the interim meeting, the following problem with the
iqn (iSCSI qualified name) format was brought up.  From
David's draft notes:

   There is a problem with domain names changing ownership
   without record of what iSCSI names iqns were created by
   the old owner.  This risks unacceptable duplication.
   Suggestions for using IANA private enterprise identifier,
   date, and some sort of existing vendor identifier were made.
   The simple approach of using WWNs runs into administrative
   difficulties like a $1500 fee to get initial allocation.

Anyway, the basic point of the iqn format is to allow hardware
and software vendors, service providers, and possibly end users
to manage their own iSCSI name spaces as they see fit.  To do
so, some sort of naming authority must be used.  To avoid having
to administer naming authorities, we may consider only existing
schemes that are already widely used and understood.  It would
be beneficial to select a scheme where entities in all of the
categories mentioned above (hw, sw, services) will already own
a name or number suitable for use as a naming authority.

Possible schemes include:

1. OUI-based schemes (including EUI-64) - These schemes are all
   based on using the IEEE organizationally unique idenfier.  These
   cost $1250 each, and are 24-bit numbers (22 bits, if also used
   for MAC addresses) assigned for use within MAC addresses and
   similar binary addresses such as EUI-64 WWNs.

   + Works fine for hardware vendors
   + Cannot be re-assigned
   - Most software vendors do not already have OUIs
   - Service providers and end users will not (and probably should
     not) be allocating OUIs.
   - Wastes part of the available MAC address space
   - Less transcribable - OUI normally expressed as six-digit hex
     number; schemes such as MAC address and EUI-64 are expressed
     as 12 to 16-digit numbers.
   - Companies are not required to make their OUI public;  comparison
     of an OUI with a list of assigned OUIs is not guaranteed to
     determine the naming authority's true identity.

   iSCSI already does provide a way to use EUI-64 addresses as
   an iSCSI name, so this functionality is already there for those
   who wish to use it.  In the end, OUIs are really meant to be
   used for lower-level, hardware-based addresses; iSCSI names identify
   higher-level software entities.  While the hardware-based scheme
   is definitely useful, it is not the most appropriate scheme in
   all cases.

2. Enterprise number

   + They don't cost anything.
   + They are easily obtained from IANA.
   + Some software vendors and service providers already have them.
   + Cannot be re-assigned.
   + Normally expressed as four (soon to be five) digit numbers.
   + Enterprise numbers are public; it is possible to look one up
     in an easily available list to determine a naming authority's
     identity.
   - Less transcribable than a DNS name (but better than an OUI).
   - Not everyone has or needs one for other purposes; might cause
     extra load on IANA-assigned name space, especially if end users,
     researchers, or university projects start applying for them.
     In the past year, IANA has assigned about 3,000 enterprise
     numbers.

3. DNS name

   + Everyone has one; even researchers and universities can create
     their own unique names.
   + More human-friendly; a quick look at an iSCSI name reveals who
     assigned it.
   + More transcribable; it's easier to write down a name than
     a number.
   - Can expire and be re-assigned.

Choice #2 and #3 seem the most useful for naming things that are not
tied strictly to hardware.  The current method is to use the DNS name,
and to reverse it as the Java class hierarchy did to avoid confusion
with an address.  We had not seriously considered enterprise numbers
before the interim meeting.  In our last conference call, we considered
three possibilities for the iqn format:

a. Just keep the DNS name and live with the consequences

   This is what we currently have; the only issue with it is the
   fact that it can expire and be re-assigned, and name collisions
   can result.

b. Ditch the DNS name in favor of an enterprise number

   This might place an unnecessary load on the allocation of
   enterprise numbers by IANA.

c. Use the DNS name format for the best flexibility, but allow the
   inclusion of the enterprise number to eliminate the uniqueness-
   over-time issue.

   This format would look like:

          Ent   Naming      Defined by
    Type   #    Auth       Naming Authority
     +-+ +--+  +------+ +--------------------+
     | | |  |  |      | |                    |

     iqn.5886.com.acme.diskarrays-sn-a8675309

   The optional enterprise number is expressed in decimal between the
   iqn and the DNS naming authority.  Hardware or software companies
   shipping products will generally have an enterprise number, and can
   prefix their reversed DNS name with it; others creating their name-
   spaces can leave out the enterprise number.  Since a component of a
   DNS name cannot start with a digit, there is no risk of confusing
   the two.



So basically, anyone wanting to use an OUI can already do so, using the
EUI-64 format.  Anyone needing to define iSCSI names using the DNS name
format can do so as well.  Anyone wanting to ensure that their names
will never conflict with someone else's can add the enterprise number.


-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054