From: Hangbin Liu <haliu@redhat.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Hangbin Liu <liuhangbin@gmail.com>,
Linux Kernel Network Developers <netdev@vger.kernel.org>
Subject: Re: [PATCH net] ip6_tunnel: remove unreachable ICMP_REDIRECT code
Date: Tue, 9 May 2017 21:09:07 +0800 [thread overview]
Message-ID: <20170509130907.GA20757@leo.usersys.redhat.com> (raw)
In-Reply-To: <CAM_iQpWAdKve_ZxG3n+uoz_We65RV95CaKydPFYobo+pQWvjjg@mail.gmail.com>
On Mon, May 08, 2017 at 01:26:48PM -0700, Cong Wang wrote:
> On Mon, May 8, 2017 at 4:11 AM, Hangbin Liu <liuhangbin@gmail.com> wrote:
> > After call ip6_tnl_err(), the rel_type will be ether ICMPV6_DEST_UNREACH
> > or ICMPV6_PKT_TOOBIG. We will never reach ICMP_REDIRECT. So remove it.
>
> Are you sure we really don't need to handle NDISC_REDIRECT here?
Hi Cong,
I have no intend to remove any handler if we need it.
Just from the code path, after call ip6_tnl_err() without error, the rel_type
will be set to either ICMPV6_DEST_UNREACH or ICMPV6_PKT_TOOBIG. Which mean the
NDISC_REDIRECT check will never be reached. That's the reason I removed it.
So if we still want to handle it, I think we need a check in ip6_tnl_err().
Please correct me if I missed anything. You know I'm a fresher here.
>
> I can't find anything in RFC 2473 explictly, but I am feeling we should handle
> it rather than ignoring it according to:
>
> To report a problem detected inside the tunnel to the source of an
> original packet, the tunnel entry point node must relay the ICMP
> message received from inside the tunnel to the source of that
> original IPv6 packet.
As I understand, the problem is detected inside the tunnel and should
reply to the source of original packet.
In section 8.1 Tunnel ICMP Messages
The tunnel ICMP messages that are reported to the source of the
original packet are:
hop limit exceeded
unreachable node
parameter problem
packet too big
Also what I understand that a redirect msg may happen looks like
A: Original Packet Source Node
B: Tunnel Entry-Point Node
C: Tunnel Exit-Point Node
D: Original Packet Destination Node
A -- B -- Node 1 -- C -- D
\- Node 2 -/
When B send msg to C, there may have a redirect from Node 1 to B, which
should be a ICMP error inside the tunnel. Not tunnel entry point to original
souce.
Or looks like
A: Original Packet Source Node
BE: Tunnel Entry-Point Node
CF: Tunnel Exit-Point Node
D: Original Packet Destination Node
A -- B -- C -- D
\- E -- F -/
When A send pkt to D, and B reply a redirect msg to A. But I think this
problem is not detected _inside_ tunnel.
Thanks
Hangbin
prev parent reply other threads:[~2017-05-09 13:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-08 11:11 [PATCH net] ip6_tunnel: remove unreachable ICMP_REDIRECT code Hangbin Liu
2017-05-08 19:59 ` David Miller
2017-05-09 3:25 ` Hangbin Liu
2017-05-08 20:26 ` Cong Wang
2017-05-09 13:09 ` Hangbin Liu [this message]
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=20170509130907.GA20757@leo.usersys.redhat.com \
--to=haliu@redhat.com \
--cc=liuhangbin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@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).