Sean Hefty wrote in response to Arkady Kanevsky: > > What's this proposal defines is basically a 65th bit for the > service ID. If the new 65 bit SID is: > > 1 <anything> - private data has this format > 0 <anything> - private data format is unknown > > Why do we need this 65th bit? >
Because current software can set any of the 64 bits. There is no assurance that any bit within the current 64 being set means that privileged software on the remote side is vouching for the standardized portion of the private data. An NFS daemon today knows that the remote IP address of an established connection is consistent with the local routing configured at the privileged layer in at least two locations (the local machine and the remote peer). Because an IP address is not used for routing we are already losing some of that. Having *neither* end be validated by the network stack is a serious change in the semantics of a connection request. Daemons frqeuently use the remote IP address to validate at least some clients as being "local" and hence trusted. On an IP network this is amazingly effective if combined with ingress filtering. But even if there is no ingress filtering, an established connection with a local IP address is inherently local. It is at most single packets, or those outside of a connection, that are suspect. Unless there is information in the REQ that cannot be set by a current CM in response to a non-privileged request then the Daemon loses this ability of inferrig "neighbor status" based on the remote IP address. That is simply no longer "IP compatible" connection establishment. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
