RE: NAT and SendTargets (was Errata to -20)

[Black_David@emc.com]

Eddy,

> I thought the original idea was that the address and ip address were not
required
> unless necessary (which would cover the NAT case). I further thought that
the
> change in the errata was to fix that.

Julian has already explained that you are incorrect, and what you think does
not match what the approved version of the iSCSI draft requires.  This sort
of change is not appropriate during the last 48 hours before RFC
publication.
If you or anyone else wants to "fix" iSCSI NAT support, "Send Draft".
 
[... snip ...]

> I already thought about your solution (to have the administrator name the
> IP address). The problem I have with that is the fact that the NAT box may
> be using DHCP. In that case the administrator would have to go to the NAT
> box each time it is booted and see what address it got.

That reflects an implementation decision in the NAT; it is not inherent.
DHCP can support statically associating IP addresses with interface MACs.
Not all NATs support this and the rest of what's needed to support
a server at a fixed IP address behind a NAT; if one wants to run a server
behind a NAT that doesn't support running a server behind the NAT, one
needs a new NAT ...
 
> BTW, can you name a case that will involve "additional complexity" where
> the proposal will not work. I just want to understand that.

More than one interface in use by iSCSI where one needs to return contact
info for each.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------