[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

    • To:
    • Subject: RE: NAT and SendTargets (was Errata to -20)
    • From: Eddy Quicksall <>
    • Date: Wed, 10 Sep 2003 13:00:59 -0400
    • Cc:
    • Content-Type: multipart/alternative;boundary="----_=_NextPart_001_01C377BD.1C0379E0"
    • Delivered-To:
    • Delivered-To:
    • Delivered-To:
    • Delivered-To:
    • Sender:

    Title: Message

    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.


    I understand where you're coming from. But I don't have time now to write such a proposal. If anyone else thinks it is an issue, then let me know and I'll try to do that later.


    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.


    BTW, can you name a case that will involve "additional complexity" where the proposal will not work. I just want to understand that.




    -----Original Message-----
    From: []
    Wednesday, September 10, 2003 12:39 PM
    Subject: NAT and SendTargets (was Errata to -20)




    I'm sorry, but that's incorrect.  If the target is running "behind a NAT

    box", it is the responsibility of the administrator(s) of the NAT box

    and the target to assign a stable public-side (of NAT) IP address to

    the target (which may be mapped to a different private-side IP address

    if the NAT is being used for something like renumbering), and configure

    that address to be returned by SendTargets.  Your proposed approach to

    NAT support will not work for any configurations that have any additional

    complexity that requires IP addresses to be returned.


    If you want to see iSCSI change to support access through NATs, write

    an Internet-Draft - NAT support changes that result in behavior on

    the wire changes and potential breakage of initiator code are not

    appropriate for the final 24 hours editorial changes prior to RFC





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

    -----Original Message-----
    From: Eddy Quicksall []
    Wednesday, September 10, 2003 8:40 AM
    To: Julian Satran;
    Subject: RE: iSCSI - Errata - to 20



    The appendix change is necessary for this reason:


    Suppose the target is running behind a NAT box. If the NAT box does not support UPnP, then the target has no way to determine the actual IP address. If the initiator just logged in, then it must already know the port and IP address.




    -----Original Message-----
    From: Julian Satran []
    Sent: Wednesday, September 10, 2003 2:03 AM
    Subject: RE: iSCSI - Errata - to 20


    Thanks - minor comments in text - Julo wrote on 10/09/2003 03:32:07:

    > I've reviewed the set of changes on Julian's web site.
    > Here are my comments, explanations, and instructions in some cases.
    > > -several editorial glitches (wording, typos)
    > One of these glitches was a mistake in the specification of TASK REASSIGN in
    > Section 10.5.1.  I suspect there are very few implementations of this, as
    > anyone who tried should have discovered that the wording was reflexive -
    > "Initiator Task Tag" refers to the Task Management Request itself, making it
    > only possible to reassign the TASK REASSIGN Request (oops).  That's clearly
    > broken, and the fix is to change to "Referenced Task Tag".
    > Section 10.17.3 adds a sentence to say that StatSN is advanced by a Reject.
    > I don't believe that changes behavior and it is a useful clarification.
    > The third paragraph in Appendix D relaxes the requirements on the amount
    > of info returned by SendTargets when there is only one target.  While
    > reasonable in design intent, this may break initiator code that is not
    > expecting to be short-changed in this fashion, and hence I think this
    > change should not be made (but I'll listen to strong counterarguments).

    I am sorry - I added inadvertently this text when looking over and trying to digest all TargetPortalTag key and value usages. I did no realize the "break scenario" you suggested.
    > > -version raised to 0x01 (that was agreed/dictated on the list to happen
    > > when RFC is issued to distinguish RFC-level from pre RFC level).
    > As stated earlier, this change to Section 10.12.4 is NOT to be made.
    > > -IESG required text for CHAP administrative domains
    > Important catch, thanks.
    > > -clarifying that some chap keys that can have in theory an arbitrary
    > number
    > > of bits have in iSCSI a length that is a multiple of 8bits
    > This was done by disallowing keys that don't have an appropriate length.  At
    > this stage, I think this is ok vs. the alternative of requiring padding,
    > esp. as a party who's confused enough to send a weird length key may also
    > be confused enough to get the padding wrong.  I think this falls into the
    > "clearly broken, needs to be fixed" category.
    > There are also a number of clarifications to the CHAP text in 11.1.4 that
    > are ok as they make the required behavior more explicit.
    > > -clarifying that TargetPortalGroup does not have to be returned in some
    > cases
    > This does change on-the-wire behavior, but only by removing the requirement
    > to return this value in cases where it is clearly of no use to the party
    > who receives it.  I believe this is ok, but will listen to objections.
    > > -the UA related text for abort (in both relevant places)
    > Once WG Last Call closes on the command ordering draft (assuming it closes
    > without objection to this point) a sentence saying which ASC/ASCQ code T10
    > has defined for this case needs to be added in both places.

    I think that the agreement reached at the time was that we won't  give the codes (other SCSI documents do the same - the argument being to minimize fixes needed in case of change).

    > -references
    > >-port numbers (default unchanged but can be overridden with the system port
    > 860)
    > Text is a little unclear - see my separate response to Eddy.
    > > Please have look and comment (before we say good bye :-))
    > Done,
    > --David
    > ----------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 176 South St., Hopkinton, MA  01748
    > +1 (508) 293-7953             FAX: +1 (508) 293-7786
    >        Mobile: +1 (978) 394-7754
    > ----------------------------------------------------


Last updated: Wed Sep 10 20:19:36 2003
12887 messages in chronological order