Subject: [Ips] no DHCP-assigned InitiatorName

From: Michael Howard <[email-masked]>
Date: Sun, 21 Sep 2008 21:24:59 -0400

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
[email-masked]

----

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Mon, 22 Sep 2008 07:07:35 -0400

Michael - I am not sure what you are looking for? A standard parameter as 
those described by the iBOOT RFC?

In any case the initiator name is not the only way to control what a 
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 
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-masked]>
To:
[email-masked]
Date:
09/21/2008 21:56
Subject:
[Ips] no DHCP-assigned InitiatorName

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.

Vendor Extensions

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

Michael Howard
Scalent Systems

----

----

QLogic
* hardware iSCSI HBAs

Intel

Broadcom
* 
http://www.broadcom.com/collateral/wp/FSC-BRCM-iSCSI-BOOT-White-Paper.pdf

IBM

emBoot

applicable to emBoot?s current products.

etherboot/gPXE

THE END

---

From: Michael Howard <[email-masked]>
Date: Mon, 22 Sep 2008 09:16:22 -0400

Julian Satran wrote:
> Michael - I am not sure what you are looking for? A standard parameter 
> as those described by the iBOOT RFC?

Yes, I am looking for a specific DHCP parameter that defines what 
InitiatorName is to be used by the iSCSI boot client.

It seems to me that the purpose of RFC4173 was/is to allow stateless 
clients to boot. The target parameters that are specified in RFC4173 are 
necessary, but not sufficient. On many commercial iSCSI target servers 
you must have the InitiatorName in order to be able to log in to the 
target. This is the case for NetApp and SANRAD, and I strongly for many 
others.

> 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 does not depend on things that can be so easy faked by 
> an initiator as the initiator name and may be easier to deploy.

This is not something that I am familiar with ...

*** 10 minutes later ***

I could find no reference to CbCS or Command Based Command Security at 
the NetApp support site now.netapp.com

A quick search at www.t10.org didn't turn anything up either ... I'll 
keep looking.

There may (and should) be other/better security mechanisms working their 
way through the standardization and implementation processes.

As a practical measure, I believe that a DHCP-supplied InitiatorName is 
needed because InitiatorName is required by many commercial iSCSI target 
servers.

Michael

---

From: Julian Satran <[email-masked]>
Date: Mon, 22 Sep 2008 09:28:59 -0400

Michael,

I think that some of the OSs have the initiator name wired into the image 
and boot providers will have to set this name.
I am not sure how what exactly is required for each version.
The boot RFC defines where the image comes from but very little else.

Sivan may give you a pointer to CbCS.

Regards,
Julo

From:
Michael Howard <[email-masked]>
To:
Julian Satran/Haifa/IBM@IBMIL
Cc:
[email-masked]
Date:
09/22/2008 09:19
Subject:
Re: [Ips] no DHCP-assigned InitiatorName

*** 10 minutes later ***

Michael

---

From: Michael Howard <[email-masked]>
Date: Mon, 22 Sep 2008 11:41:17 -0400

Julian Satran wrote:
> Michael,
> 
> I think that some of the OSs have the initiator name wired into the 
> image and boot providers will have to set this name.

I do not understand what you are trying to say.

On x86 architectures the iBFT (iSCSI Boot Firmware Table) is used to 
pass iSCSI boot parameters to the OS. The iSCSI boot parameters include 
target information and InitiatorName ... so that a new session 
(attaching to the same LUN) can be established by the OS driver.

> The boot RFC defines where the image comes from but very little else.

I am arguing that "very little else" is actually too little ;)

> Sivan may give you a pointer to CbCS.

OK

Michael

---

From: [email-masked]
Date: Mon, 22 Sep 2008 11:41:12 -0400

CbCS is a technology for which there is little to no current product
support.  As a security technology, it does not strike me as a good
solution to the issue that Michael raises, which is basically an
automatic configuration issue.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julian Satran
	Sent: Monday, September 22, 2008 9:29 AM
	To: Michael Howard
	Cc: Sivan Tal; [email-masked]
	Subject: Re: [Ips] no DHCP-assigned InitiatorName

	Michael, 
	
	I think that some of the OSs have the initiator name wired into
the image and boot providers will have to set this name. 
	I am not sure how what exactly is required for each version. 
	The boot RFC defines where the image comes from but very little
else. 

	Regards, 
	Julo 

From: 	Michael Howard <[email-masked]> 
To: 	Julian Satran/Haifa/IBM@IBMIL 
Cc: 	[email-masked] 
Date: 	09/22/2008 09:19 
Subject: 	Re: [Ips] no DHCP-assigned InitiatorName

________________________________

	
	> as those described by the iBOOT RFC?
	
	Yes, I am looking for a specific DHCP parameter that defines
what 
	InitiatorName is to be used by the iSCSI boot client.
	
	It seems to me that the purpose of RFC4173 was/is to allow
stateless 
	clients to boot. The target parameters that are specified in
RFC4173 are 
	necessary, but not sufficient. On many commercial iSCSI target
servers 
	you must have the InitiatorName in order to be able to log in to
the 
	target. This is the case for NetApp and SANRAD, and I strongly
for many 
	others.

	
	*** 10 minutes later ***
	
	I could find no reference to CbCS or Command Based Command
Security at 
	the NetApp support site now.netapp.com
	
	A quick search at www.t10.org didn't turn anything up either ...
I'll 
	keep looking.

	There may (and should) be other/better security mechanisms
working their 
	way through the standardization and implementation processes.
	
	As a practical measure, I believe that a DHCP-supplied
InitiatorName is 
	needed because InitiatorName is required by many commercial
iSCSI target 
	servers.

	Michael

---

From: [email-masked]
Date: Mon, 22 Sep 2008 12:04:32 -0400

A couple of procedural notes:

> 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.

The IP Storage WG has been closed, BUT this list is still a fine place
to discuss this sort of topic, and it can be addressed via an individual
Internet-Draft (a WG is not required to do work).

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

Considering that DHCP has no real security, one cannot pass the CHAP
secret in the clear via DHCP.  The CHAP username should not cause a
problem.

Thanks,
--David

---

From: Michael Howard <[email-masked]>
Date: Mon, 22 Sep 2008 13:12:21 -0400

> Internet-Draft (a WG is not required to do work).

Understood.

> secret in the clear via DHCP.  The CHAP username should not cause a

I agree.

Michael

---

From: Julian Satran <[email-masked]>
Date: Mon, 22 Sep 2008 13:19:58 -0400

Michael,

I will have to defer to boot RFC authors. My 2 cents is that DHCP 
"practice" has already several mechanisms to name the initiator (most 
based on what the DHCP agents present to the DHCP server - like the real 
of "fake" (for VMs) MAC address. And I don't know how the iBFT interacts 
(or is supposed to) with a DHCP server.

Regards,
Julo

From:
Michael Howard <[email-masked]>
To:
Julian Satran/Haifa/IBM@IBMIL
Cc:
[email-masked], Sivan Tal/Haifa/IBM@IBMIL
Date:
09/22/2008 11:42
Subject:
Re: [Ips] no DHCP-assigned InitiatorName

OK

Michael

---

From: Michael Howard <[email-masked]>
Date: Mon, 22 Sep 2008 14:10:26 -0400

Julian Satran wrote:
> of "fake" (for VMs) MAC address. 

I agree that there are several different mechanisms that are used to 
construct the initiator name. In practice, what we have ended up with is:

This is a problem because almost every commercially available iSCSI 
target uses the initiator name as an identification mechanism to control 
visibility to target LUNs.

As a result, trying to move from one iSCSI boot initiator to another 
requires changes on the SAN storage controller (or iSCSI head) to 
reconfigure for the new initiator name. This is unnecessarily 
complicated and, in many commercial environments, forces coordination 
across different organizational units.

> And I don't know how the iBFT interacts 

There is no *direct* interaction between the DHCP server and the iBFT. 
Rather, the values get passed through the iSCSI boot initiator.

The boot iSCSI initiator is responsible for populating the iBFT with the 
iSCSI parameters that are required to continue to boot the OS once it 
switches to its protected-mode drivers.

The relevant fields in the iBFT are:
  * portal hostname/ip addr
  * portal port
  * target name
  * target lun
  * initiator name
  * CHAP stuff

The iSCSI boot initiator fills in these fields regardless of whether the 
parameters come from EEPROM config or from a DHCP server. The values 
that are filled in are the same values used by the boot initiator for 
its iSCSI login.

Michael

---

From: Michael Howard <[email-masked]>
Date: Mon, 22 Sep 2008 14:13:49 -0400

Thank you for the reference and explanation.

This looks like it may be useful down the road as the standard becomes 
adopted and commercial implementations become available.

Michael

Sivan Tal wrote:
> Michael,
> 
> CbCS (Capability-based Command Security) is part of the SPC-4 (SCSI Primary
> Commands) standard draft.
> The current version is in
> http://www.t10.org/ftp/t10/drafts/spc4/spc4r16.pdf
> Clause 5.14.6 described Command Security, and sub-clause 5.14.6.8 describes
> CbCS, which is currently the only SCSI command security technique.
> 
> Using CbCS, the initiator provides credential to the target that authorizes
> it to access the target logical unit. The credential does not contain an
> initiator identity and it is obtained from a trusted third party (security
> manager) and "signed" with HMAC (based on a symmetric key shared between
> the security manager and the target).  The credential (the Capability
> descriptor) contains a DISCRIMINATOR field that can be set in a "vendor
> specific" manner. One can use that field for initiator identifier. However,
> it should be noted that when using CbCS you don't need this for
> authorization. The access decision point is in the security manager and the
> access enforcement point is in the target device, based on the credential.
> The initiator authenticates only to the security manager, thus keeping the
> device simple. This is especially valuable in virtualized environments.
> 
> Sivan Tal
> IBM.
> 
> 
> 
> |------------>
> | From:      |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |Julian Satran/Haifa/IBM                                                                                                                           |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To:        |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |Michael Howard <[email-masked]>                                                                                                       |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc:        |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   [email-masked], Sivan Tal/Haifa/IBM@IBMIL                                                                                                           |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date:      |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |09/22/2008 09:29 AM                                                                                                                               |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject:   |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |Re: [Ips] no DHCP-assigned InitiatorName                                                                                                          |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> 
> 
> 
> 
> Michael,]
> 
> |------------>
> | From:      |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |Michael Howard <[email-masked]>                                                                                                       |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | To:        |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |Julian Satran/Haifa/IBM@IBMIL                                                                                                                     |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Cc:        |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   [email-masked]                                                                                                                                      |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Date:      |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |09/22/2008 09:19                                                                                                                                  |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> |------------>
> | Subject:   |
> |------------>
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
>   |Re: [Ips] no DHCP-assigned InitiatorName                                                                                                          |
>   >--------------------------------------------------------------------------------------------------------------------------------------------------|
> 
> 
> 
> 
> 
> 
> 
> Julian Satran wrote:

---

From: <[email-masked]>
Date: Tue, 23 Sep 2008 00:32:22 +0530

My 2cents on the issue. Please correct me if I am wrong. 

Shouldn't it be possible to configure the isns server with a set of
possibly regex rules for the control path. If this not possible today,
then it could possibly be the root to take towards standardizing. 

This can solve the problem of provisioning for dynamic boot environments
with minimum changes to legacy iqn implementations, many of which would
need to relearn to the new iqn mechanism that might end up as a result
of this discussion. Instead of changing numerous configurations we could
simply change the isns server control mechanism.

Comments?

-Shyam Iyer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Howard
Sent: Monday, September 22, 2008 11:40 PM
To: Julian Satran
Cc: Sivan Tal; Prasenjit Sarkar; [email-masked]
Subject: Re: [Ips] no DHCP-assigned InitiatorName

Julian Satran wrote:
> based on what the DHCP agents present to the DHCP server - like the 
> real of "fake" (for VMs) MAC address.

I agree that there are several different mechanisms that are used to
construct the initiator name. In practice, what we have ended up with
is:

> And I don't know how the iBFT interacts (or is supposed to) with a 
> DHCP server.

Michael

---

From: Michael Howard <[email-masked]>
Date: Mon, 22 Sep 2008 15:28:30 -0400

> My 2cents on the issue. Please correct me if I am wrong. 

Thank you for participating in this discussion.

> then it could possibly be the root to take towards standardizing. 

I am not familiar enough with iSNS to comment.

I have been exposed to about about a dozen commercial environments with 
some level of iSCSI use/experimentation. I am not aware that any of them 
  were running iSNS servers.

> of this discussion.

Frankly, my concern is that Broadcom/IBM already have a non-standard 
DHCP Vendor Option work-around for this problem.

Adding a new/standardized InitiatorName DHCP option would not break 
existing initiator implementations. Vendors would integrate support for 
this new InitiatorName option into their code/firmware releases over time.

> Instead of changing numerous configurations we could

I need to do some homework regarding iSNS.

> Comments?

iSCSI is still a very small part of the market.

I advocate addressing this deficiency sooner rather than later.

Michael

---

From: <[email-masked]>
Date: Mon, 22 Sep 2008 14:46:01 -0500

My 2 cents based on my understanding of iSNS. 

- iSNS clients (initiators and targets) need to have an IQN address
before they register with the iSNS server.
- Most pre-OS iSCSI initiators available today are not iSNS clients i.e.
they don't register with and/or query iSNS server.

Given this, it seems better to have a DHCP based standardized mechanism
for acquiring the initiator IQN. Based on initial email from Michael,
most pre-OS iSCSI Initiators available today have the capability to be a
DHCP client.

Thanks,
Gaurav Chawla
Technology Strategist, Network Storage Architecture | Office of the CTO,
Dell, Inc.
Phone: 512.724.4064 (work)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Howard
Sent: Monday, September 22, 2008 2:29 PM
To: Iyer, Shyam
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Ips] no DHCP-assigned InitiatorName

Adding a new/standardized InitiatorName DHCP option would not break 
existing initiator implementations. Vendors would integrate support for 
this new InitiatorName option into their code/firmware releases over
time.

Michael

---

From: <[email-masked]>
Date: Tue, 23 Sep 2008 01:37:22 +0530

Thanks Gaurav. 
You are right. The fact that most of the pre-OS iSCSI initiators don't
have iSNS clients, takes us away from the iSNS scenario atleast for the
boot environment.

On the other hand the scenario where in there are iSNS clients(or a more
enterprise ready environment) we could probably think more on the lines
of security since parameters with DHCP(clear text) is going to be less
secure.

Thanks,
Shyam Iyer

-----Original Message-----
From: Chawla, G 
Sent: Tuesday, September 23, 2008 1:16 AM
To: Michael Howard; Iyer, Shyam
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Chawla, G
Subject: RE: [Ips] no DHCP-assigned InitiatorName

Thanks,
Gaurav Chawla

-----Original Message-----

> This can solve the problem of provisioning for dynamic boot 
> environments with minimum changes to legacy iqn implementations, many 
> of which would need to relearn to the new iqn mechanism that might end

> up as a result of this discussion.

> Instead of changing numerous configurations we could simply change the

> isns server control mechanism.

Michael

---

From: <[email-masked]>
Date: Mon, 22 Sep 2008 16:18:40 -0500

We should be able to leverage CHAP based security (already defined for
iSCSI) to provide the necessary security (authentication) between the
initiators and targets. 

Thanks,
Gaurav Chawla

-----Original Message-----
From: Iyer, Shyam 
Sent: Monday, September 22, 2008 3:07 PM
To: Chawla, G; 'Michael Howard'
Cc: [email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'
Subject: RE: [Ips] no DHCP-assigned InitiatorName

Thanks Gaurav. 

Thanks,
Shyam Iyer

-----Original Message-----
From: Chawla, G 
Sent: Tuesday, September 23, 2008 1:16 AM
To: Michael Howard; Iyer, Shyam
Cc: [email-masked]; [email-masked]; [email-masked];

Thanks,
Gaurav Chawla

-----Original Message-----

Michael

---

From: Sivan Tal <[email-masked]>
Date: Mon, 22 Sep 2008 11:50:36 -0400

Michael,

Sivan Tal
IBM.

|------------>
| From:      |
|------------>
|------------>
| To:        |
|------------>
|------------>
| Cc:        |
|------------>
|------------>
| Date:      |
|------------>
  |09/22/2008 09:29 AM                                                                                                                               |
|------------>
| Subject:   |
|------------>

Michael,]

Regards,
Julo

|------------>
| From:      |
|------------>
|------------>
| To:        |
|------------>
|------------>
| Cc:        |
|------------>
  [email-masked]                                                                                                                                      |
|------------>
| Date:      |
|------------>
  |09/22/2008 09:19                                                                                                                                  |
|------------>
| Subject:   |
|------------>

*** 10 minutes later ***

Michael

---

From: Michael Howard <[email-masked]>
Date: Wed, 24 Sep 2008 14:59:04 -0700

Gaurav and Shyam,

Q: Do you have contacts with the EqualLogic team who may be interested 
in working on a resolution for this iSCSI/DHCP issue?

Q: Do you have any contacts at Broadcom?

Thanks,
Michael

[email-masked] wrote:
> environments