[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140107231737.GM30393@order.stressinduktion.org>
Date: Wed, 8 Jan 2014 00:17:37 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: Bill Fink <billfink@...dspring.com>,
Francois-Xavier Le Bail <fx.lebail@...oo.com>,
netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki Yoshifuji <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH net-next v5] IPv6: add the option to use anycast addresses as source addresses in echo reply
On Wed, Jan 08, 2014 at 12:01:34AM +0100, Hannes Frederic Sowa wrote:
> On Tue, Jan 07, 2014 at 05:55:07PM -0500, Bill Fink wrote:
> > On Tue, 7 Jan 2014, Francois-Xavier Le Bail wrote:
> >
> > > This change allows to follow a recommandation of RFC4942.
> > >
> > > - Add "anycast_src_echo_reply" sysctl to control the use of anycast addresses
> > > as source addresses for ICMPv6 echo reply. This sysctl is false by default
> > > to preserve existing behavior.
> > > - Add inline check ipv6_anycast_destination().
> > > - Use them in icmpv6_echo_reply().
> > >
> > > Reference:
> > > RFC4942 - IPv6 Transition/Coexistence Security Considerations
> > > (http://tools.ietf.org/html/rfc4942#section-2.1.6)
> > >
> > > 2.1.6. Anycast Traffic Identification and Security
> > >
> > > [...]
> > > To avoid exposing knowledge about the internal structure of the
> > > network, it is recommended that anycast servers now take advantage of
> > > the ability to return responses with the anycast address as the
> > > source address if possible.
> > >
> > > Signed-off-by: Francois-Xavier Le Bail <fx.lebail@...oo.com>
> > > ---
> > > v4: update Subject and Documentation, this work also with anycast addresses
> > > created via API, not just with Subnet-Router anycast addresses.
> > >
> > > v5: alternative way, replace ipv6_chk_acast_addr() test by
> > > ipv6_anycast_destination() test.
> >
> > Why is ICMPV6 Echo Reply special? Can't the internal structure
> > of the network be divined from other ICMPv6 responses such as
> > Destination Unreachable, Time Exceeded (Hop Limit), and Parameter
> > Problem.
>
> No, here destination must match the source address so that the other side
> handles accordingly when the icmp error is pushed up to the socket layer.
I forgot to mention, rest of kernel followes the old RFC advise to never
use anycast addresses as source addresses.
I guess this will be weakend with upcoming patches so in future this
depends on socket settings and other tweaks. If that's the case default will
be to also respond with anycast source if original destination was anycast.
Greetings,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists