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

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

    > This sort of change is not appropriate during the last 48 hours before RFC
    Yes, I know and I already pointed out that I understand.
    Please understand that I'm not trying to argue a point but I just want to
    fully understand where this would be a problem.
    To review ... the idea would be that the initiator could login using an IP
    address for discovery but the target being discovered is on the same address
    that was used for discovery (as may be used behind a NAT box).
    If this doesn't make sense, I don't want to submit a draft proposal.
    > More than one interface in use by iSCSI where one needs to return contact
    > info for each.
    The case I was trying to point out is the case where the only IP address
    would be the one the initiator used for his discovery. In that case, I don't
    see why he would need the address given back.
    If I'm still misunderstanding you, please clear that up.
    >DHCP can support statically associating IP addresses with interface MACs.
    There may be better examples but over cable modem the NAT can't use a static
    IP address.
    > one needs a new NAT ...
    I thought part of our criteria with iSCSI was to work with existing
    BTW, there is something called UpNP and the target could use that to get the
    address of the NAT box (if you have a conforming NAT box). But I'm not sure
    that will work where you have cascaded NAT's.


Last updated: Thu Sep 11 09:19:30 2003
12890 messages in chronological order