On 7/9/15 9:55 PM, Eric W. Biederman wrote:
IP addresses are per interface and interfaces are uniquely assigned to
a VRF so why do you think IP addresses are not per VRF?
I have read large swaths of the linux networking code over the years.
Further I was thinking more about non-local addresses ip addresses, but
I would not be surprised if there are also issues with local addresses.
Well, if someone has a specific example I'll take a look.
Which means things like packet fragmentation reassembly
can easily do the wrong thing. Similarly things like the xfrm for ipsec
tunnels are not hooked into this mix.
So I really do not see how this VRF/MRF thing as designed can support
general purpose sockets. I am not certain it can correctly support any
kind of socket except perhaps SOCK_RAW.
Sockets bound to the VRF device work properly. Why do you think they won't?
Because there are many locations in the network stack (like fragment
reassembly) that make the assumption that ip addresses are unique and
do not bother looking at network device or anything else. If fragments
manage to come into play I don't expect it would be hard to poision a
connections with fragments from another routing domain with overlapping
ip addresses.
If that is true it is a problem with the networking stack today and is
completely independent of this VRF proposal.
I guess if we are talking about SO_BINDTODEVICE which requires
CAP_NET_RAW we aren't really talking ordinary applications so there is
already a big helping of buyer beware.
Still a blanket statement that sockets just work and there is nothing
to be concerned about is just wrong.
If you have examples of something that does not work I will be happy to
look into it. As it stands I have a growing suite of test cases where my
comment is true.
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
