On 7/27/15 2:30 PM, Eric W. Biederman wrote:
This paragraph is false when it comes to sockets, as I have already
pointed out.
- VPN Routing and Forwarding (RFC4364 and it's kin) implies isolation
strong enough to allow using the the same ip on different machines
in different VPN instances and not have confusion.
- The routing table is not the only table in the kernel that uses
an ip address as a key.
The result is that you can combine packets fragments that come in
on different interfaces (irrespective of your VPN), confuse tcp
parameters between interfaces, scramble your ipsec connections and I
don't know what else.
The duplicate IP address is a problem with the networking stack today;
the VRF device does not introduce it. The VRF device does allow
duplicate IP addresses within a namespace but separate VRFs, though yes
various places that rely solely on source address like IP fragmentation
do need to be fixed.
I looked at the IPv4 fragmentation code yesterday and will continue
today. So help me with the history: is there any reason why the device
index is not used today? It seems like a straight forward change.
1. simple netdevices with the same IP address
--> no problem using index in the lookup
2. 2 ipsec tunnels -- different netdevices, same IP address
--> no problem using index
3. stacked devices like bonding and team interfaces appear to the stack
as a single device
--> no problem using index of stacked device
4. If an interface is deleted and a new one is created with the same IP
address then we want to fail the lookup
--> no problem using index
5. other???
Is there a use case where I can't add ifindex of the incoming device (or
higher level device if skb->dev is changed) to the hash and lookup for
fragments?
Version 3
- addressed comments from first 2 RFCs with the exception of the name
Nicolas: We will do the name conversion once we agree on what the
correct name should be (vrf, mrf or something else)
Not so. I described the deep problems between your goals and your
implementation and they are not even mentioned let alone addressed.
I have addressed comments to the extent that I can. As I stated in my
last followup to you Eric I did not understand your point. I asked for
clarification, a --verbose if you will. I can't read your mind, so I
need you to elaborate on your points to be able to respond and address
your concerns.
- packets flow through the VRF device in both directions allowing the
following:
- tcpdump -i vrf<n>
- tc rules on vrf device
- netfilter rules on vrf device
Ingo/Andy: I added you two as a start point for the proposed task related
changes. Not sure who should be the reviewer; please let me know
if someone else is more appropriate. Thanks.
It looks like you are trying to implement a namespace that isn't a
namespace. Given that it is broken by design you have my nack.
This is an L3 separation within a namespace, not a device level
separation which is what namespaces provide.
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
