[openib-general] Re: [PATCH] CMA: allow/require bind beforeconnect

Caitlin Bestler caitlinb at broadcom.com
Mon Mar 27 13:15:49 PST 2006


Roland Dreier wrote:
> OK, fair enough.  I was really replying to the first sentence of:
> 
>      Caitlin> From the perspective of any given host, IP addresses are
>      Caitlin> unique across all interface devices. A given connection
>      Caitlin> can therefore be identified by just the 4-tuple, with no
>      Caitlin> need to explicitly state "via this device".
> 
> IP addresses are not unique.  However, I do agree that a
> 4-tuple uniquely identifies a TCP connection.
> 
>  - R.

>From RFC 1918:

   An enterprise that decides to use IP addresses out of the address
   space defined in this document can do so without any coordination
   with IANA or an Internet registry. The address space can thus be used
   by many enterprises. Addresses within this private address space will
   only be unique within the enterprise, or the set of enterprises which
   choose to cooperate over this space so they may communicate with each
   other in their own private internet.

So the unique scope of the IP address is limited to the enterprise,
rather than being global. But that scope still encompasses any
one single host. It is incorrect to have two "private" networks
with the same network prefix attached to the same host. If both
eth0 and eth1 claim to be 192.168.1.1, how will a request to
connect to 192.168.1.2 be processed? Are they redundant
interfaces to the same subnet (leaving the only problem 
being the determination of which MAC address should be
in the ARP reply), or are they two different networks
where the 192.168.1.2 they will reach could be different
hosts entirely?

A given IP address reaches *one* remote host (or a cluster
pretending to be a single remote host). There is no ambiguity
allowed. And if the local IP address belongs to the same
subnet then there can be no ambiguity about the local IP
address either.

The semantics of an IP address should not be affected by
the underlying transport.




More information about the general mailing list