[Ips] no DHCP-assigned InitiatorName

[Michael Howard <[e-mail]>]

I am writing this memo to the IETF IP Storage Working Group to voice my 
concern over the apparent lack of IETF or industry standard for having a 
DHCP server pass an InitiatorName to an iSCSI boot client.

This issue may be something that you are already aware of, and may be 
something that you are already working to address.

(I am going to ignore the related issues of CHAP username and secret)

rfc4173 [http://tools.ietf.org/html/rfc4173 Bootstrapping Clients using 
the Internet Small Computer System Interface (iSCSI) Protocol) defines 
the protocol for passing boot target information to an iSCSI boot client 
via DHCP options. Unfortunately, it does not define a mechanism for 
passing an InitiatorName to be used by the iSCSI boot initiator. The 
omission of this has led to differences in the InitiatorName in 
different iSCSI boot implementations.

Many iSCSI target servers depend upon the iSCSI InitiatorName to control 
visibility to target LUNs. The inability to control InitiatorName 
through DHCP leads to interoperability issues as one tries to 
dynamically move between systems with different iSCSI boot implementations.

I am not familiar with iSNS (Internet Storage Naming Service 
http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName 
probably plays a key role in identification.

I am familiar with several currently available implementations of iSCSI 
initiators ... hardware, firmware, and software. see listing below.

The hardware and firmware implementations of iSCSI boot initiators 
(QLogic, Intel, Broadcom, IBM) allow one to define static initiator and 
target login information in EEPROM on the client. In addition, they all 
support a DHCP assigned iSCSI boot target per RFC 4173.

The etherboot/gPXE implementation only supports assignment of iSCSI boot 
parameters via DHCP.

Implementations generally construct the InitiatorName by trying to 
include the DHCP option 12 hostname. They take a base iSCSI Qualified 
Name prefix and concatenate the hostname supplied by the DHCP server. 
You end up with:

  iqn.1987-05.com.intel:<hostname>
  iqn.2000-01.org.etherboot:<hostname>
  iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
  iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname>

<hostname> represents the hostname provided in DHCP option 12.
<11.22.33.44.55.66> represents the MAC address of the initiator NIC.

This might work fine in a static data-center environment where dedicated 
applications run on dedicated hardware. Even a mixed environment with 
different vendors involved is generally not a problem as long as each 
system is configured individually ... and as long as no system changes 
are required.

However, data centers and data center configurations are not static. 
They frequently have a need to move from one hardware configuration to 
another. Common examples are a planned hardware upgrade of an existing 
system and an emergency hardware replacement for a failed system. A more 
extreme example would be an offsite disaster-recovery scenario.

Machine virtualization tools such as vmWare and Zen facilitate moving 
images between systems, easing the transition between system hardware.

Data center virtualization systems such as Scalent automate assignment 
of SAN-based applications to available servers in the server pool, 
effectively enabling a data center to run any application on any 
available physical or virtual machine.

Migrating iSCSI boot images from one system to another is problematic if 
the iSCSI boot implementations differ between the old hardware and new 
hardware. On many/most commercial iSCSI target servers the 
visibility/mapping/zoning configuration would have to change because of 
the differing iSCSI InitiatorName. This is a problem because it usually 
requires coordination across organizational units.

Take the case where one has an application running on an IBM server 
using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One 
wishes to move this application to an HP server with an Intel NIC that 
supports iSCSI boot. Both iSCSI initiators support DHCP assignment of 
the iSCSI target. However, since the full InitiatorName is not specified 
via DHCP, the SAN administrator must also make a change on the iSCSI SAN 
storage controller in order to make the appropriate LUN(s) visible to 
the new/different initiator name.

Vendor Extensions

Broadcom and IBM seem to have foreseen this oversight in rfc4713. From 
available documentation it is unclear to me whether or not they have 
adopted exactly the same mechanism as a workaround for assigning the 
iSCSI boot initiator name. I am in the process of obtaining hardware so 
that I can verify behavior.

Broadcom documentation indicates that they support a DHCP vendor 
extension that allows one to fully specify the InitiatorName from the 
DHCP server. Support for an option such as this would mean that 
boot-from-iSCSI-SAN images could be moved between systems by only making 
changes on the DHCP server. See 
http://ftp.us.dell.com/network/Bcom_LAN_11.0_4.1_Manual_A01.exe

Draft IBM documentation at 
ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf 
indicates that the initiator name can be set using DHCP vendor option 
203 … but it isn’t very specific … and I have not been able to verify this.

I have also been told that the Microsoft WHQL (Windows Hardware Quality 
Labs) requirements for iSCSI boot make reference to “DHCP option 203”. I 
am trying to obtain these documents.


Conclusion

There needs to be a standard IETF mechanism, perhaps an extension to 
rfc4713, that defines what InitiatorName is to be used when iSCSI booting.

I am interested in participating in the discussion and am willing to 
help however I can.


Michael Howard
Scalent Systems
[e-mail]

----

Internet Small Computer Systems Interface (iSCSI)
http://tools.ietf.org/html/rfc3720

Internet Small Computer Systems Interface (iSCSI)
Naming and Discovery
http://tools.ietf.org/html/rfc3721

String Profile for Internet Small Computer
Systems Interface (iSCSI) Names
http://tools.ietf.org/html/rfc3722

Internet Storage Naming Service (iSNS)
http://tools.ietf.org/html/rfc4171

Bootstrapping Clients using the Internet
Small Computer System Interface (iSCSI) Protocol
http://tools.ietf.org/html/rfc4173

----

QLogic
* hardware iSCSI HBAs
* proprietary drivers for Win + Linux
* http://qlogic.com/Products/SAN_products_iSCSI.aspx
* supports DHCP assignment of target parameters

Intel
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >= win2k3
* http://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=15864
* iqn.1987-05.com.intel:<hostname>

Broadcom
* iSCSI boot firmware for selected server-class NICs
* works in conjunction with MSFT initiator under >= win2k3
* http://www.broadcom.com/collateral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf
* iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot
* Vendor extension DHCP option 43 suboption 203

IBM
* iSCSI NIC firmware in selected blades/servers
* works in conjunction with MSFT initiator under >= win2k3
* http://www.alphaworks.ibm.com/tech/sancommander
* ftp://ftp.software.ibm.com/systems/support/system_x_pdf/39y9159.pdf
* vendor extension option 203

emBoot
* software PXE/UNDI implementation
* proprietary windows initiator under XP & win2k with netBoot/i
* works with MSFT initiator under >= win2k3
* http://emboot.com/iscsiboot.htm

emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i 
products to assign login information to their software initiator. emBoot 
does not support DHCP assignment of iSCSI boot parameters. Therefore, 
the discussion of DHCP assignment of iSCSI boot parameters is not 
applicable to emBoot’s current products.

etherboot/gPXE
* open source PXE/UNDI/NIC driver implementation
* works with MSFT initiator under >= win2k3
* http://etherboot.org/wiki/index.php
* only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473.


THE END
_______________________________________________
Ips mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ips