Re: no DHCP-assigned InitiatorName
Julian Satran <[email protected]> Mon, 22 Sep 2008 07:07:35 -0400
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <OF51EB8C4B.4A802DE0-ON852574CC.003C9899-852574CC.003D1E7C@il.ibm.com> |
This is a multipart message in MIME format. --===============1724665744== Content-Type: multipart/alternative; boundary="=_alternative 003D1C63852574CC_=" This is a multipart message in MIME format. --=_alternative 003D1C63852574CC_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Michael - I am not sure what you are looking for? A standard parameter as=20 those described by the iBOOT RFC? In any case the initiator name is not the only way to control what a=20 server will access. CbCS (stands for Credential Based Command Security) available for any SCSI = device at the SCSI layer (see the T10 site) is probably safer/better and=20 does not depend on things that can be so easy faked by an initiator as the = initiator name and may be easier to deploy. Regards, Julo From: Michael Howard <[email protected]> To: [email protected] Date: 09/21/2008 21:56 Subject: [Ips] no DHCP-assigned InitiatorName I am writing this memo to the IETF IP Storage Working Group to voice my=20 concern over the apparent lack of IETF or industry standard for having a=20 DHCP server pass an InitiatorName to an iSCSI boot client. This issue may be something that you are already aware of, and may be=20 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=20 the Internet Small Computer System Interface (iSCSI) Protocol) defines=20 the protocol for passing boot target information to an iSCSI boot client=20 via DHCP options. Unfortunately, it does not define a mechanism for=20 passing an InitiatorName to be used by the iSCSI boot initiator. The=20 omission of this has led to differences in the InitiatorName in=20 different iSCSI boot implementations. Many iSCSI target servers depend upon the iSCSI InitiatorName to control=20 visibility to target LUNs. The inability to control InitiatorName=20 through DHCP leads to interoperability issues as one tries to=20 dynamically move between systems with different iSCSI boot=20 implementations. I am not familiar with iSNS (Internet Storage Naming Service=20 http://tools.ietf.org/html/rfc4171) but I assume that the InitiatorName=20 probably plays a key role in identification. I am familiar with several currently available implementations of iSCSI=20 initiators ... hardware, firmware, and software. see listing below. The hardware and firmware implementations of iSCSI boot initiators=20 (QLogic, Intel, Broadcom, IBM) allow one to define static initiator and=20 target login information in EEPROM on the client. In addition, they all=20 support a DHCP assigned iSCSI boot target per RFC 4173. The etherboot/gPXE implementation only supports assignment of iSCSI boot=20 parameters via DHCP. Implementations generally construct the InitiatorName by trying to=20 include the DHCP option 12 hostname. They take a base iSCSI Qualified=20 Name prefix and concatenate the hostname supplied by the DHCP server.=20 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=20 applications run on dedicated hardware. Even a mixed environment with=20 different vendors involved is generally not a problem as long as each=20 system is configured individually ... and as long as no system changes=20 are required. However, data centers and data center configurations are not static.=20 They frequently have a need to move from one hardware configuration to=20 another. Common examples are a planned hardware upgrade of an existing=20 system and an emergency hardware replacement for a failed system. A more=20 extreme example would be an offsite disaster-recovery scenario. Machine virtualization tools such as vmWare and Zen facilitate moving=20 images between systems, easing the transition between system hardware. Data center virtualization systems such as Scalent automate assignment=20 of SAN-based applications to available servers in the server pool,=20 effectively enabling a data center to run any application on any=20 available physical or virtual machine. Migrating iSCSI boot images from one system to another is problematic if=20 the iSCSI boot implementations differ between the old hardware and new=20 hardware. On many/most commercial iSCSI target servers the=20 visibility/mapping/zoning configuration would have to change because of=20 the differing iSCSI InitiatorName. This is a problem because it usually=20 requires coordination across organizational units. Take the case where one has an application running on an IBM server=20 using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One=20 wishes to move this application to an HP server with an Intel NIC that=20 supports iSCSI boot. Both iSCSI initiators support DHCP assignment of=20 the iSCSI target. However, since the full InitiatorName is not specified=20 via DHCP, the SAN administrator must also make a change on the iSCSI SAN=20 storage controller in order to make the appropriate LUN(s) visible to=20 the new/different initiator name. Vendor Extensions Broadcom and IBM seem to have foreseen this oversight in rfc4713. From=20 available documentation it is unclear to me whether or not they have=20 adopted exactly the same mechanism as a workaround for assigning the=20 iSCSI boot initiator name. I am in the process of obtaining hardware so=20 that I can verify behavior. Broadcom documentation indicates that they support a DHCP vendor=20 extension that allows one to fully specify the InitiatorName from the=20 DHCP server. Support for an option such as this would mean that=20 boot-from-iSCSI-SAN images could be moved between systems by only making=20 changes on the DHCP server. See=20 http://ftp.us.dell.com/network/Bcom=5FLAN=5F11.0=5F4.1=5FManual=5FA01.exe Draft IBM documentation at=20 ftp://ftp.software.ibm.com/systems/support/system=5Fx=5Fpdf/39y9159.pdf=20 indicates that the initiator name can be set using DHCP vendor option=20 203 ? but it isn?t very specific ? and I have not been able to verify=20 this. I have also been told that the Microsoft WHQL (Windows Hardware Quality=20 Labs) requirements for iSCSI boot make reference to ?DHCP option 203?. I=20 am trying to obtain these documents. Conclusion There needs to be a standard IETF mechanism, perhaps an extension to=20 rfc4713, that defines what InitiatorName is to be used when iSCSI booting. I am interested in participating in the discussion and am willing to=20 help however I can. Michael Howard Scalent Systems [email protected] ---- 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=5Fproducts=5FiSCSI.aspx * supports DHCP assignment of target parameters Intel * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >=3D win2k3 * http://downloadcenter.intel.com/Detail=5FDesc.aspx?DwnldID=3D15864 * iqn.1987-05.com.intel:<hostname> Broadcom * iSCSI boot firmware for selected server-class NICs * works in conjunction with MSFT initiator under >=3D win2k3 *=20 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 >=3D win2k3 * http://www.alphaworks.ibm.com/tech/sancommander * ftp://ftp.software.ibm.com/systems/support/system=5Fx=5Fpdf/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 >=3D win2k3 * http://emboot.com/iscsiboot.htm emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i=20 products to assign login information to their software initiator. emBoot=20 does not support DHCP assignment of iSCSI boot parameters. Therefore,=20 the discussion of DHCP assignment of iSCSI boot parameters is not=20 applicable to emBoot?s current products. etherboot/gPXE * open source PXE/UNDI/NIC driver implementation * works with MSFT initiator under >=3D win2k3 * http://etherboot.org/wiki/index.php * only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473. THE END =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ips mailing list [email protected] https://www.ietf.org/mailman/listinfo/ips --=_alternative 003D1C63852574CC_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <font size=3D2 face=3D"sans-serif">Michael - I am not sure what you are loo= king for? A standard parameter as those described by the iBOOT RFC?</font> <br> <br><font size=3D2 face=3D"sans-serif">In any case the initiator name is not the only way to control what a server will access.</font> <br> <br><font size=3D2 face=3D"sans-serif">CbCS (stands for Credential Based Co= mmand Security) available for any SCSI device at the SCSI layer (see the T10 site) is probably safer/better and does not depend on things that can be so easy faked by an initiator as the initiator name and may be easier to deploy.</font> <br> <br><font size=3D2 face=3D"sans-serif">Regards,</font> <br><font size=3D2 face=3D"sans-serif">Julo</font> <br> <br> <br> <br> <br> <table width=3D100%> <tr valign=3Dtop> <td><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">From:</font> <td><font size=3D1 face=3D"sans-serif">Michael Howard <michael.howard@sc= alent.com></font> <tr valign=3Dtop> <td><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">To:</font> <td><font size=3D1 face=3D"sans-serif">[email protected]</font> <tr valign=3Dtop> <td><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Date:</font> <td><font size=3D1 face=3D"sans-serif">09/21/2008 21:56</font> <tr valign=3Dtop> <td><font size=3D1 color=3D#5f5f5f face=3D"sans-serif">Subject:</font> <td><font size=3D1 face=3D"sans-serif">[Ips] no DHCP-assigned InitiatorName= </font></table> <br> <hr noshade> <br> <br> <br><tt><font size=3D2>I am writing this memo to the IETF IP Storage Working Group to voice my <br> concern over the apparent lack of IETF or industry standard for having a <br> DHCP server pass an InitiatorName to an iSCSI boot client.<br> <br> This issue may be something that you are already aware of, and may be <br> something that you are already working to address.<br> <br> (I am going to ignore the related issues of CHAP username and secret)<br> <br> rfc4173 [</font></tt><a href=3Dhttp://tools.ietf.org/html/rfc4173><tt><font= size=3D2>http://tools.ietf.org/html/rfc4173</font></tt></a><tt><font size= =3D2> Bootstrapping Clients using <br> the Internet Small Computer System Interface (iSCSI) Protocol) defines <br> the protocol for passing boot target information to an iSCSI boot client <br> via DHCP options. Unfortunately, it does not define a mechanism for <br> passing an InitiatorName to be used by the iSCSI boot initiator. The <br> omission of this has led to differences in the InitiatorName in <br> different iSCSI boot implementations.<br> <br> Many iSCSI target servers depend upon the iSCSI InitiatorName to control <br> visibility to target LUNs. The inability to control InitiatorName <br> through DHCP leads to interoperability issues as one tries to <br> dynamically move between systems with different iSCSI boot implementations.= <br> <br> I am not familiar with iSNS (Internet Storage Naming Service <br> </font></tt><a href=3Dhttp://tools.ietf.org/html/rfc4171><tt><font size=3D2= >http://tools.ietf.org/html/rfc4171</font></tt></a><tt><font size=3D2>) but I assume that the InitiatorName <br> probably plays a key role in identification.<br> <br> I am familiar with several currently available implementations of iSCSI <br> initiators ... hardware, firmware, and software. see listing below.<br> <br> The hardware and firmware implementations of iSCSI boot initiators <br> (QLogic, Intel, Broadcom, IBM) allow one to define static initiator and <br> target login information in EEPROM on the client. In addition, they all <br> support a DHCP assigned iSCSI boot target per RFC 4173.<br> <br> The etherboot/gPXE implementation only supports assignment of iSCSI boot <br> parameters via DHCP.<br> <br> Implementations generally construct the InitiatorName by trying to <br> include the DHCP option 12 hostname. They take a base iSCSI Qualified <br> Name prefix and concatenate the hostname supplied by the DHCP server. <br> You end up with:<br> <br> iqn.1987-05.com.intel:<hostname><br> iqn.2000-01.org.etherboot:<hostname><br> iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot<br> iqn.1986-03.com.ibm.<11:22:33:44:55:66>.<hostname><br> <br> <hostname> represents the hostname provided in DHCP option 12.<br> <11.22.33.44.55.66> represents the MAC address of the initiator NIC.<= br> <br> This might work fine in a static data-center environment where dedicated <br> applications run on dedicated hardware. Even a mixed environment with <br> different vendors involved is generally not a problem as long as each <br> system is configured individually ... and as long as no system changes <br> are required.<br> <br> However, data centers and data center configurations are not static. <br> They frequently have a need to move from one hardware configuration to <br> another. Common examples are a planned hardware upgrade of an existing <br> system and an emergency hardware replacement for a failed system. A more <br> extreme example would be an offsite disaster-recovery scenario.<br> <br> Machine virtualization tools such as vmWare and Zen facilitate moving <br> images between systems, easing the transition between system hardware.<br> <br> Data center virtualization systems such as Scalent automate assignment <br> of SAN-based applications to available servers in the server pool, <br> effectively enabling a data center to run any application on any <br> available physical or virtual machine.<br> <br> Migrating iSCSI boot images from one system to another is problematic if <br> the iSCSI boot implementations differ between the old hardware and new <br> hardware. On many/most commercial iSCSI target servers the <br> visibility/mapping/zoning configuration would have to change because of <br> the differing iSCSI InitiatorName. This is a problem because it usually <br> requires coordination across organizational units.<br> <br> Take the case where one has an application running on an IBM server <br> using iSCSI boot. iSCSI boot parameters are being assigned via DHCP. One <br> wishes to move this application to an HP server with an Intel NIC that <br> supports iSCSI boot. Both iSCSI initiators support DHCP assignment of <br> the iSCSI target. However, since the full InitiatorName is not specified <br> via DHCP, the SAN administrator must also make a change on the iSCSI SAN <br> storage controller in order to make the appropriate LUN(s) visible to <br> the new/different initiator name.<br> <br> Vendor Extensions<br> <br> Broadcom and IBM seem to have foreseen this oversight in rfc4713. From <br> available documentation it is unclear to me whether or not they have <br> adopted exactly the same mechanism as a workaround for assigning the <br> iSCSI boot initiator name. I am in the process of obtaining hardware so <br> that I can verify behavior.<br> <br> Broadcom documentation indicates that they support a DHCP vendor <br> extension that allows one to fully specify the InitiatorName from the <br> DHCP server. Support for an option such as this would mean that <br> boot-from-iSCSI-SAN images could be moved between systems by only making <br> changes on the DHCP server. See <br> </font></tt><a href=3Dhttp://ftp.us.dell.com/network/Bcom=5FLAN=5F11.0=5F4.= 1=5FManual=5FA01.exe><tt><font size=3D2>http://ftp.us.dell.com/network/Bcom= =5FLAN=5F11.0=5F4.1=5FManual=5FA01.exe</font></tt></a><tt><font size=3D2><b= r> <br> Draft IBM documentation at <br> </font></tt><a href=3Dftp://ftp.software.ibm.com/systems/support/system=5Fx= =5Fpdf/39y9159.pdf><tt><font size=3D2>ftp://ftp.software.ibm.com/systems/su= pport/system=5Fx=5Fpdf/39y9159.pdf</font></tt></a><tt><font size=3D2> <br> indicates that the initiator name can be set using DHCP vendor option <br> 203 … but it isn’t very specific … and I have not been ab= le to verify this.<br> <br> I have also been told that the Microsoft WHQL (Windows Hardware Quality <br> Labs) requirements for iSCSI boot make reference to “DHCP option 203&= #8221;. I <br> am trying to obtain these documents.<br> <br> <br> Conclusion<br> <br> There needs to be a standard IETF mechanism, perhaps an extension to <br> rfc4713, that defines what InitiatorName is to be used when iSCSI booting.<= br> <br> I am interested in participating in the discussion and am willing to <br> help however I can.<br> <br> <br> Michael Howard<br> Scalent Systems<br> [email protected]<br> <br> ----<br> <br> Internet Small Computer Systems Interface (iSCSI)<br> </font></tt><a href=3Dhttp://tools.ietf.org/html/rfc3720><tt><font size=3D2= >http://tools.ietf.org/html/rfc3720</font></tt></a><tt><font size=3D2><br> <br> Internet Small Computer Systems Interface (iSCSI)<br> Naming and Discovery<br> </font></tt><a href=3Dhttp://tools.ietf.org/html/rfc3721><tt><font size=3D2= >http://tools.ietf.org/html/rfc3721</font></tt></a><tt><font size=3D2><br> <br> String Profile for Internet Small Computer<br> Systems Interface (iSCSI) Names<br> </font></tt><a href=3Dhttp://tools.ietf.org/html/rfc3722><tt><font size=3D2= >http://tools.ietf.org/html/rfc3722</font></tt></a><tt><font size=3D2><br> <br> Internet Storage Naming Service (iSNS)<br> </font></tt><a href=3Dhttp://tools.ietf.org/html/rfc4171><tt><font size=3D2= >http://tools.ietf.org/html/rfc4171</font></tt></a><tt><font size=3D2><br> <br> Bootstrapping Clients using the Internet<br> Small Computer System Interface (iSCSI) Protocol<br> </font></tt><a href=3Dhttp://tools.ietf.org/html/rfc4173><tt><font size=3D2= >http://tools.ietf.org/html/rfc4173</font></tt></a><tt><font size=3D2><br> <br> ----<br> <br> QLogic<br> * hardware iSCSI HBAs<br> * proprietary drivers for Win + Linux<br> * </font></tt><a href=3Dhttp://qlogic.com/Products/SAN=5Fproducts=5FiSCSI.a= spx><tt><font size=3D2>http://qlogic.com/Products/SAN=5Fproducts=5FiSCSI.as= px</font></tt></a><tt><font size=3D2><br> * supports DHCP assignment of target parameters<br> <br> Intel<br> * iSCSI boot firmware for selected server-class NICs<br> * works in conjunction with MSFT initiator under >=3D win2k3<br> * </font></tt><a href=3D"http://downloadcenter.intel.com/Detail=5FDesc.aspx= ?DwnldID=3D15864"><tt><font size=3D2>http://downloadcenter.intel.com/Detail= =5FDesc.aspx?DwnldID=3D15864</font></tt></a><tt><font size=3D2><br> * iqn.1987-05.com.intel:<hostname><br> <br> Broadcom<br> * iSCSI boot firmware for selected server-class NICs<br> * works in conjunction with MSFT initiator under >=3D win2k3<br> * </font></tt><a href=3D"http://www.broadcom.com/collateral/wp/FSC-BRCM-iSC= SI-BOOT-White-Paper.pdf"><tt><font size=3D2>http://www.broadcom.com/collate= ral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf</font></tt></a><tt><font size=3D= 2><br> * iqn.1995-05.com.broadcom.<11.22.33.44.55.66>.iscsiboot<br> * Vendor extension DHCP option 43 suboption 203<br> <br> IBM<br> * iSCSI NIC firmware in selected blades/servers<br> * works in conjunction with MSFT initiator under >=3D win2k3<br> * </font></tt><a href=3Dhttp://www.alphaworks.ibm.com/tech/sancommander><tt= ><font size=3D2>http://www.alphaworks.ibm.com/tech/sancommander</font></tt>= </a><tt><font size=3D2><br> * </font></tt><a href=3Dftp://ftp.software.ibm.com/systems/support/system= =5Fx=5Fpdf/39y9159.pdf><tt><font size=3D2>ftp://ftp.software.ibm.com/system= s/support/system=5Fx=5Fpdf/39y9159.pdf</font></tt></a><tt><font size=3D2><b= r> * vendor extension option 203<br> <br> emBoot<br> * software PXE/UNDI implementation<br> * proprietary windows initiator under XP & win2k with netBoot/i<br> * works with MSFT initiator under >=3D win2k3<br> * </font></tt><a href=3Dhttp://emboot.com/iscsiboot.htm><tt><font size=3D2>= http://emboot.com/iscsiboot.htm</font></tt></a><tt><font size=3D2><br> <br> emBoot uses a proprietary mechanism in their netBoot/i and winBoot/i <br> products to assign login information to their software initiator. emBoot <br> does not support DHCP assignment of iSCSI boot parameters. Therefore, <br> the discussion of DHCP assignment of iSCSI boot parameters is not <br> applicable to emBoot’s current products.<br> <br> etherboot/gPXE<br> * open source PXE/UNDI/NIC driver implementation<br> * works with MSFT initiator under >=3D win2k3<br> * </font></tt><a href=3Dhttp://etherboot.org/wiki/index.php><tt><font size= =3D2>http://etherboot.org/wiki/index.php</font></tt></a><tt><font size=3D2>= <br> * only (?) supports DHCP assignment of iSCSI boot parameters per RFC 1473.<= br> <br> <br> THE END<br> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br> Ips mailing list<br> [email protected]<br> </font></tt><a href=3Dhttps://www.ietf.org/mailman/listinfo/ips><tt><font s= ize=3D2>https://www.ietf.org/mailman/listinfo/ips</font></tt></a><tt><font = size=3D2><br> </font></tt><br> <br> <br> --=_alternative 003D1C63852574CC_=-- --===============1724665744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ips mailing list [email protected] https://www.ietf.org/mailman/listinfo/ips --===============1724665744==--