From: David Miller <davem@davemloft.net>
To: zenczykowski@gmail.com
Cc: netdev@vger.kernel.org, yoshfuji@linux-ipv6.org
Subject: Re: [PATCH] net: Fix IPv6 PMTU disc. w/ asymmetric routes
Date: Sun, 03 Oct 2010 14:49:31 -0700 (PDT) [thread overview]
Message-ID: <20101003.144931.71122620.davem@davemloft.net> (raw)
In-Reply-To: <20100930.004136.91329579.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 30 Sep 2010 00:41:36 -0700 (PDT)
> Maybe the problem is that the ipv6 side uses the same saddr for both
> the lookup and the entry comparison in these PMTU code paths? Does it
> not allow specifying them seperately as the ipv4 PMTU (and incidently
> the RT redirect) code paths do?
>
> Or is this not an issue on the ipv6 side for some reason?
Ok, meanwhile I did the research.
What ipv6 does is that when you lookup a route, it clones or copies
the prefixes route into one that is fully specified for a specific
SADDR/DADDR pair, and then inserts that specific route into the FIB6
tree.
Therefore the only cases we should lookup for PMTU discovery for ipv6
are:
{ daddr, saddr, ifindex == 0 }
{ daddr, saddr, ifindex == dev->ifindex }
This achieves the same effect as what ipv4 is doing.
So Maciej your original attempt was correct all along, and as a result
I'll commit the following.
Thanks!
--------------------
net: Fix IPv6 PMTU disc. w/ asymmetric routes
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv6/route.c | 28 ++++++++++++++++++++++++----
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 8323136..a275c6e 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1556,14 +1556,13 @@ out:
* i.e. Path MTU discovery
*/
-void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
- struct net_device *dev, u32 pmtu)
+static void rt6_do_pmtu_disc(struct in6_addr *daddr, struct in6_addr *saddr,
+ struct net *net, u32 pmtu, int ifindex)
{
struct rt6_info *rt, *nrt;
- struct net *net = dev_net(dev);
int allfrag = 0;
- rt = rt6_lookup(net, daddr, saddr, dev->ifindex, 0);
+ rt = rt6_lookup(net, daddr, saddr, ifindex, 0);
if (rt == NULL)
return;
@@ -1631,6 +1630,27 @@ out:
dst_release(&rt->dst);
}
+void rt6_pmtu_discovery(struct in6_addr *daddr, struct in6_addr *saddr,
+ struct net_device *dev, u32 pmtu)
+{
+ struct net *net = dev_net(dev);
+
+ /*
+ * RFC 1981 states that a node "MUST reduce the size of the packets it
+ * is sending along the path" that caused the Packet Too Big message.
+ * Since it's not possible in the general case to determine which
+ * interface was used to send the original packet, we update the MTU
+ * on the interface that will be used to send future packets. We also
+ * update the MTU on the interface that received the Packet Too Big in
+ * case the original packet was forced out that interface with
+ * SO_BINDTODEVICE or similar. This is the next best thing to the
+ * correct behaviour, which would be to update the MTU on all
+ * interfaces.
+ */
+ rt6_do_pmtu_disc(daddr, saddr, net, pmtu, 0);
+ rt6_do_pmtu_disc(daddr, saddr, net, pmtu, dev->ifindex);
+}
+
/*
* Misc support functions
*/
--
1.7.3.1
next prev parent reply other threads:[~2010-10-03 21:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 4:43 [PATCH] IPv6: fix rt_lookup in pmtu_discovery Tom Herbert
2010-01-07 9:27 ` David Miller
2010-01-08 1:05 ` Maciej Żenczykowski
2010-01-08 1:10 ` David Miller
2010-01-09 0:12 ` Lorenzo Colitti
2010-01-10 21:15 ` David Miller
2010-01-14 0:51 ` Maciej Żenczykowski
2010-01-20 22:55 ` Maciej Żenczykowski
2010-01-20 22:57 ` David Miller
2010-01-20 23:33 ` Maciej Żenczykowski
2010-01-23 10:20 ` David Miller
2010-09-27 10:05 ` [PATCH] net: Fix IPv6 PMTU disc. w/ asymmetric routes Maciej Żenczykowski
[not found] ` <AANLkTikPOHy79E1ZG=iJ-rHj0vzS+AY-mGqCEtWoXp2o@mail.gmail.com>
2010-09-27 18:11 ` David Miller
2010-09-28 20:58 ` David Miller
2010-09-28 22:37 ` Maciej Żenczykowski
2010-09-30 7:41 ` David Miller
2010-10-03 21:49 ` David Miller [this message]
2010-10-04 0:21 ` Maciej Żenczykowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101003.144931.71122620.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
--cc=zenczykowski@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).