Allow receiving packets on the fallback tunnel if they pass sanity checks
Subsystems (3)
PATCH 1/1 Allow receiving packets on the fallback tunnel if they pass sanity checks
Ville Nuorvala wrote this patch to solve a problem we were having at Facebook. He hasn't had time to send it upstream yet, but gave me permission to do it, and I want to make sure it makes it upstream by World v6 Launch Day.
Quoted 1 line
From
b413062771afbba064ae9bc49b5daed7abb1243dMon Sep 17 00:00:00 2001
From: Ville Nuorvala <[email protected]>
Subject: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checks
The same IPv6 address checks are performed as with any normal tunnel, but as the fallback tunnel endpoint addresses are unspecified, the checks must be performed on a per-packet basis, rather than at tunnel configuration time.
--- include/net/ip6_tunnel.h | 2 + net/ipv6/ip6_tunnel.c | 65 +++++++++++++++++++++++++++------------------- 2 files changed, 40 insertions(+), 27 deletions(-)
include/net/ip6_tunnel.h +2 -0
@@ -9,6 +9,8 @@#define IP6_TNL_F_CAP_XMIT 0x10000/* capable of receiving packets */ #define IP6_TNL_F_CAP_RCV 0x20000 +/* determine capability on a per-packet basis */ +#define IP6_TNL_F_CAP_PER_PACKET 0x40000/* IPv6 tunnel */
net/ipv6/ip6_tunnel.c +38 -27
107 lines not on this page · raw message
Signature · 7 lines
Phil Dibowitz [email protected] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss
David Miller
maintainerFrom: Phil Dibowitz <[email protected]>
Date: Tue, 5 Jun 2012 08:40:58 -0700
Quoted 1 line
and I want to make sure it makes it upstream by World v6 Launch Day.
Submitting a patch just a day or two beforehand is absolutely not the way to achieve this.
It's a pointless deadline anyways, even if I put it in today it would be months to years before the majority of real users actually have it running on their machines.
Quoted 7 lines · David Miller
From: Phil Dibowitz <[email protected]>
Date: Tue, 5 Jun 2012 08:40:58 -0700Quoted 1 line
and I want to make sure it makes it upstream by World v6 Launch Day.
Submitting a patch just a day or two beforehand is absolutely not the way to achieve this.
My wording was poor. I didn't expect it to be in the kernel, I just wanted to at least get it out the door by then.
Signature · 7 lines
Phil Dibowitz [email protected] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss
David Miller
maintainerFrom: Phil Dibowitz <[email protected]>
Date: Tue, 5 Jun 2012 08:40:58 -0700
Quoted 11 lines
From
b413062771afbba064ae9bc49b5daed7abb1243dMon Sep 17 00:00:00 2001
From: Ville Nuorvala <[email protected]>
Subject: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checksThe same IPv6 address checks are performed as with any normal tunnel, but as the fallback tunnel endpoint addresses are unspecified, the checks must be performed on a per-packet basis, rather than at tunnel configuration time.
Signed-off-by Ville Nuorvala <[email protected]>Tested-by Phil Dibowitz <[email protected]>
I've reviewed this change but I still have no idea why it's necessary.
You need to compose a more lengthy and detailed commit log message explaining everything before I'm going to consider applying this patch.
You can't just say "we have some problem at Facebook, this patch fixes it", and then merely describe word by word the content of the patch without explaining the "why". That simply doesn't cut it.
Thanks.
Quoted 18 lines · David Miller
From: Phil Dibowitz <[email protected]>
Date: Tue, 5 Jun 2012 08:40:58 -0700Quoted 11 lines
From
b413062771afbba064ae9bc49b5daed7abb1243dMon Sep 17 00:00:00 2001
From: Ville Nuorvala <[email protected]>
Subject: [PATCH] Allow receiving packets on the fallback tunnel if they pass sanity checksThe same IPv6 address checks are performed as with any normal tunnel, but as the fallback tunnel endpoint addresses are unspecified, the checks must be performed on a per-packet basis, rather than at tunnel configuration time.
Signed-off-by Ville Nuorvala <[email protected]>Tested-by Phil Dibowitz <[email protected]>I've reviewed this change but I still have no idea why it's necessary.
Quoted 7 lines
You need to compose a more lengthy and detailed commit log message explaining everything before I'm going to consider applying this patch.
You can't just say "we have some problem at Facebook, this patch fixes it", and then merely describe word by word the content of the patch without explaining the "why". That simply doesn't cut it.
Sure. Sorry, I just kept Ville's patch description.
We do Layer-3 DSR via IP-in-IP tunneling. Our load balancers wrap an extra IP header on incoming packets so they can be routed to the backend. In the v4 tunnel driver, when these packets fall on the default tunl0 device, the behavior is to decapsulate them and drop them back on the stack. So our setup is that tunl0 has the VIP and eth0 has (obviously) the backend's real address.
In IPv6 we do the same thing, but the v6 tunnel driver didn't have this same behavior - if you didn't have an explicit tunnel setup, it would drop the packet.
This patch brings that v4 feature to the v6 driver.
I think that's the level of detail you're looking for, but I'm happy to expand on anything in particular. I also break this down in tons of detail here:
Signature · 7 lines
Phil Dibowitz [email protected] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind." - Dr. Seuss
David Miller
maintainerFrom: Phil Dibowitz <[email protected]>
Date: Mon, 25 Jun 2012 20:37:35 -0700
Quoted 8 lines
Sure. Sorry, I just kept Ville's patch description.
We do Layer-3 DSR via IP-in-IP tunneling. Our load balancers wrap an extra IP header on incoming packets so they can be routed to the backend. In the v4 tunnel driver, when these packets fall on the default tunl0 device, the behavior is to decapsulate them and drop them back on the stack. So our setup is that tunl0 has the VIP and eth0 has (obviously) the backend's real address.
Quoted 7 lines
In IPv6 we do the same thing, but the v6 tunnel driver didn't have this same behavior - if you didn't have an explicit tunnel setup, it would drop the packet.
This patch brings that v4 feature to the v6 driver.
I think that's the level of detail you're looking for, but I'm happy to expand on anything in particular. I also break this down in tons of detail here:
This is a lot better, please resubmit the patch with a proper verbose commit message, and please submit it properly and without any unrelated content in the message body as described in Documentation/SubmittingPatches