From: "François-Xavier Le Bail" <fx.lebail@yahoo.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation
Date: Sat, 5 Nov 2011 01:39:52 -0700 (PDT) [thread overview]
Message-ID: <1320482392.98040.YahooMailNeo@web126003.mail.ne1.yahoo.com> (raw)
In-Reply-To: <1320423860.16609.4.camel@edumazet-laptop>
>From: Eric Dumazet <eric.dumazet@gmail.com>
>To: François-Xavier Le Bail <fx.lebail@yahoo.com>
>Sent: Friday, November 4, 2011 5:24 PM
>Subject: Re: [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation
>
>Le vendredi 04 novembre 2011 à 07:46 -0700, François-Xavier Le Bail a
>écrit :
>> I do some tests on a Linux 3.0 kernel with IPv6 forwarding mode enabled.
>>
>> When I ping (ICMPv6 echo request) on one of its Subnet-Router anycast addresses
>> (SRAA, http://tools.ietf.org/html/rfc4291#section-2.6.1),
>> the Linux kernel reply with an unicast source address, not the anycast one.
>>
>> When I send an IPv6 UDP packet to a server on Linux on one of its SRAA,
>> the Linux kernel build a reply with an unicast source address, not the anycast one.
Thanks for your answer.
>Nothing in the kernel builds a reply to an UDP packet.
You are right. I meant that in some cases the kernel selects the source address
of the reply.
>I would say the user application is responsible to build an answer, and
>chose appropriate source address.
OK.
>If your application uses a ANY_ADDR bind, then it must appropriate
>action so that a good source address is used in answers.
>
>In case of IPv6 socket, I advise you take a look at IPV6_PKTINFO /
>IPV6_RECVPKTINFO options.
I will study and test these options for my application server.
>> The RFC 4942 states (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.
>>
>> Also, If the source address of reply differs from destination address of the request, many applications are broken.
>> Please let me know your feedback.
>>
>
>'anycast servers' are a combination of kernel and userland parts.
Agreed, but remain the case of ICMPv6 echo request/reply, which I think is in kernel.
Francois-Xavier
next prev parent reply other threads:[~2011-11-05 8:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-04 14:46 [RFC] The Linux kernel IPv6 stack don't follow the RFC 4942 recommendation François-Xavier Le Bail
2011-11-04 16:24 ` Eric Dumazet
2011-11-05 8:39 ` François-Xavier Le Bail [this message]
2011-11-05 9:20 ` Eric Dumazet
2011-11-18 10:15 ` Bjørn Mork
2011-11-05 9:30 ` Eric Dumazet
2011-11-10 10:58 ` François-Xavier Le Bail
2011-11-10 11:27 ` Eric Dumazet
2011-11-10 12:54 ` François-Xavier Le Bail
2011-11-10 15:23 ` François-Xavier Le Bail
2011-11-10 13:25 ` How to get the port values Naveen B N (nbn)
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=1320482392.98040.YahooMailNeo@web126003.mail.ne1.yahoo.com \
--to=fx.lebail@yahoo.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/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).