* [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
@ 2014-01-02 15:53 Francois-Xavier Le Bail
2014-01-02 17:17 ` Hannes Frederic Sowa
0 siblings, 1 reply; 12+ messages in thread
From: Francois-Xavier Le Bail @ 2014-01-02 15:53 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy, Francois-Xavier Le Bail
This change allows to follow a recommandation of RFC4942.
- Add "enable_anycast_src" sysctl to control the use of Subnet-Router anycast
addresses as source addresses. This sysctl is false by default to preserve
existing behavior.
- Use it in ip6_datagram_send_ctl() and 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@yahoo.com>
---
Documentation/networking/ip-sysctl.txt | 6 ++++++
include/net/netns/ipv6.h | 1 +
net/ipv6/datagram.c | 3 +++
net/ipv6/icmp.c | 4 +++-
net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
5 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index d71afa8..2a062a7 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1094,6 +1094,12 @@ bindv6only - BOOLEAN
Default: FALSE (as specified in RFC3493)
+enable_anycast_src - BOOLEAN
+ Controls the use of Subnet-Router anycast addresses as source addresses
+ TRUE: enabled
+ FALSE: disabled
+ Default: FALSE
+
IPv6 Fragmentation:
ip6frag_high_thresh - INTEGER
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 0fb2401..3d3aa86 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -73,6 +73,7 @@ struct netns_ipv6 {
#endif
atomic_t dev_addr_genid;
atomic_t rt_genid;
+ int enable_anycast_src;
};
#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 6983058..0b32095 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -668,6 +668,9 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
if (addr_type != IPV6_ADDR_ANY) {
int strict = __ipv6_addr_src_scope(addr_type) <= IPV6_ADDR_SCOPE_LINKLOCAL;
if (!(inet_sk(sk)->freebind || inet_sk(sk)->transparent) &&
+ !(net->ipv6.enable_anycast_src &&
+ ipv6_chk_acast_addr(net, NULL,
+ &src_info->ipi6_addr)) &&
!ipv6_chk_addr(net, &src_info->ipi6_addr,
strict ? dev : NULL, 0))
err = -EINVAL;
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 5d42009..1c25c85 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -556,7 +556,9 @@ static void icmpv6_echo_reply(struct sk_buff *skb)
saddr = &ipv6_hdr(skb)->daddr;
- if (!ipv6_unicast_destination(skb))
+ if (!ipv6_unicast_destination(skb) &&
+ !(net->ipv6.enable_anycast_src &&
+ ipv6_chk_acast_addr(net, NULL, saddr)))
saddr = NULL;
memcpy(&tmp_hdr, icmph, sizeof(tmp_hdr));
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index 107b2f1..67c09f5 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -24,6 +24,13 @@ static struct ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "enable_anycast_src",
+ .data = &init_net.ipv6.enable_anycast_src,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
{ }
};
@@ -51,6 +58,7 @@ static int __net_init ipv6_sysctl_net_init(struct net *net)
if (!ipv6_table)
goto out;
ipv6_table[0].data = &net->ipv6.sysctl.bindv6only;
+ ipv6_table[1].data = &net->ipv6.enable_anycast_src;
ipv6_route_table = ipv6_route_sysctl_init(net);
if (!ipv6_route_table)
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-02 15:53 Francois-Xavier Le Bail
@ 2014-01-02 17:17 ` Hannes Frederic Sowa
0 siblings, 0 replies; 12+ messages in thread
From: Hannes Frederic Sowa @ 2014-01-02 17:17 UTC (permalink / raw)
To: Francois-Xavier Le Bail
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
On Thu, Jan 02, 2014 at 04:53:48PM +0100, Francois-Xavier Le Bail wrote:
> This change allows to follow a recommandation of RFC4942.
>
> - Add "enable_anycast_src" sysctl to control the use of Subnet-Router anycast
> addresses as source addresses. This sysctl is false by default to preserve
> existing behavior.
> - Use it in ip6_datagram_send_ctl() and icmpv6_echo_reply().
It is very cool that you are working on this. I had this on my TODO list for a
long time.
> 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.
Actually, the restriction was lifted by RFC 4291 ("IP Version 6 Addressing
Architecture").
> Signed-off-by: Francois-Xavier Le Bail <fx.lebail@yahoo.com>
> ---
> Documentation/networking/ip-sysctl.txt | 6 ++++++
> include/net/netns/ipv6.h | 1 +
> net/ipv6/datagram.c | 3 +++
> net/ipv6/icmp.c | 4 +++-
> net/ipv6/sysctl_net_ipv6.c | 8 ++++++++
> 5 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index d71afa8..2a062a7 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1094,6 +1094,12 @@ bindv6only - BOOLEAN
>
> Default: FALSE (as specified in RFC3493)
>
> +enable_anycast_src - BOOLEAN
> + Controls the use of Subnet-Router anycast addresses as source addresses
> + TRUE: enabled
> + FALSE: disabled
> + Default: FALSE
> +
I wouldn't actually add this knob, we can just enable that by default.
Also it should be no problem to bind() to those addresses.
I am still unsure what to do with a bind to any or if the address must be
bound specifically (maybe that is worth a knob).
In the long term I would like to see that we can add additional anycast
addresses via iproute:
ip -6 a a 1234::1/64 dev eth0 anycast
or something like that. That should be rather easy, as in just incrementing
the anycast counter for an interface in inet6_rtm_newaddr and adding a flag
to ifa_flags which gets passed down by iproute2.
I'll do some research on if this should also get integrated with source
address selection.
Thanks very much, that is really cool,
Hannes
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
@ 2014-01-02 18:56 François-Xavier Le Bail
2014-01-02 23:17 ` Hannes Frederic Sowa
0 siblings, 1 reply; 12+ messages in thread
From: François-Xavier Le Bail @ 2014-01-02 18:56 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
On Thu, 1/2/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>> This change allows to follow a recommandation of RFC4942.
>>
>> - Add "enable_anycast_src" sysctl to control the use of Subnet-Router anycast
>> addresses as source addresses. This sysctl is false by default to preserve
>> existing behavior.
>> - Use it in ip6_datagram_send_ctl() and icmpv6_echo_reply().
> It is very cool that you are working on this. I had this on my TODO list for a
long time.
Thanks,I think also it is useful.
>> 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
>>
>> [...]
> Actually, the restriction was lifted by RFC 4291 ("IP Version 6
> Addressing Architecture").
Exact.
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index d71afa8..2a062a7 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1094,6 +1094,12 @@ bindv6only - BOOLEAN
>
> Default: FALSE (as specified in RFC3493)
>
> +enable_anycast_src - BOOLEAN
> + Controls the use of Subnet-Router anycast addresses as source addresses
> + TRUE: enabled
> + FALSE: disabled
> + Default: FALSE
> +
> I wouldn't actually add this knob, we can just enable that by default.
I think we need to keep by default the existing behaviour (ICMPv6 echo reply with unicast)
in case some setups use it, and use "enable_anycast_src" to change the behaviour
according to RFC4942.
> Also it should be no problem to bind() to those addresses.
> I am still unsure what to do with a bind to any or if the address must be
> bound specifically (maybe that is worth a knob).
> In the long term I would like to see that we can add additional anycast
> addresses via iproute:
> ip -6 a a 1234::1/64 dev eth0 anycast
> or something like that. That should be rather easy, as in just incrementing
> the anycast counter for an interface in inet6_rtm_newaddr
> and adding a flag to ifa_flags which gets passed down by iproute2.
> I'll do some research on if this should also get integrated with source address selection.
It can be the objects of future evolutions.
I have to think about these.
> Hannes
Thanks,
Francois-Xavier
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-02 18:56 [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses François-Xavier Le Bail
@ 2014-01-02 23:17 ` Hannes Frederic Sowa
2014-01-02 23:19 ` Hannes Frederic Sowa
0 siblings, 1 reply; 12+ messages in thread
From: Hannes Frederic Sowa @ 2014-01-02 23:17 UTC (permalink / raw)
To: François-Xavier Le Bail
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
On Thu, Jan 02, 2014 at 10:56:17AM -0800, François-Xavier Le Bail wrote:
> > I wouldn't actually add this knob, we can just enable that by default.
>
> I think we need to keep by default the existing behaviour (ICMPv6 echo reply with unicast)
> in case some setups use it, and use "enable_anycast_src" to change the behaviour
> according to RFC4942.
We try to extract the destination address and reuse it in the reply. The
other system should not notice if it communicates with a unicast or
anycast address. Am I missing something?
> > Also it should be no problem to bind() to those addresses.
>
> > I am still unsure what to do with a bind to any or if the address must be
> > bound specifically (maybe that is worth a knob).
>
> > In the long term I would like to see that we can add additional anycast
> > addresses via iproute:
>
> > ip -6 a a 1234::1/64 dev eth0 anycast
>
> > or something like that. That should be rather easy, as in just incrementing
> > the anycast counter for an interface in inet6_rtm_newaddr
> > and adding a flag to ifa_flags which gets passed down by iproute2.
>
> > I'll do some research on if this should also get integrated with source address selection.
>
> It can be the objects of future evolutions.
> I have to think about these.
Me, too. :) I don't know what the consequences are if we make the whole
unicast path agnostic to anycast. It could very well be a bad idea.
Thanks,
Hannes
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-02 23:17 ` Hannes Frederic Sowa
@ 2014-01-02 23:19 ` Hannes Frederic Sowa
2014-01-03 5:58 ` François-Xavier Le Bail
0 siblings, 1 reply; 12+ messages in thread
From: Hannes Frederic Sowa @ 2014-01-02 23:19 UTC (permalink / raw)
To: François-Xavier Le Bail, netdev, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki Yoshifuji,
Patrick McHardy
On Fri, Jan 03, 2014 at 12:17:30AM +0100, Hannes Frederic Sowa wrote:
> On Thu, Jan 02, 2014 at 10:56:17AM -0800, François-Xavier Le Bail wrote:
> > > I wouldn't actually add this knob, we can just enable that by default.
> >
> > I think we need to keep by default the existing behaviour (ICMPv6 echo reply with unicast)
> > in case some setups use it, and use "enable_anycast_src" to change the behaviour
> > according to RFC4942.
>
> We try to extract the destination address and reuse it in the reply. The
> other system should not notice if it communicates with a unicast or
> anycast address. Am I missing something?
Ah, I guess you are hinting at the situation where you ping a pre-defined
anycast address and expect back a unicast address for discovering the unicast
address of a router e.g.? Ok, I see...
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-02 23:19 ` Hannes Frederic Sowa
@ 2014-01-03 5:58 ` François-Xavier Le Bail
2014-01-03 6:19 ` François-Xavier Le Bail
0 siblings, 1 reply; 12+ messages in thread
From: François-Xavier Le Bail @ 2014-01-03 5:58 UTC (permalink / raw)
To: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy, Hannes Frederic Sowa
--------------------------------------------
On Thu, 1/2/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> Ah, I guess you are hinting at the situation where you ping
> a pre-defined
> anycast address and expect back a unicast address for
> discovering the unicast
> address of a router e.g.? Ok, I see...
Exact
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-03 5:58 ` François-Xavier Le Bail
@ 2014-01-03 6:19 ` François-Xavier Le Bail
2014-01-03 6:30 ` Hannes Frederic Sowa
0 siblings, 1 reply; 12+ messages in thread
From: François-Xavier Le Bail @ 2014-01-03 6:19 UTC (permalink / raw)
To: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy, Hannes Frederic Sowa
On Fri, 1/3/14, François-Xavier Le Bail <fx.lebail@yahoo.com> wrote:
--------------------------------------------
On Thu, 1/2/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>> Ah, I guess you are hinting at the situation where you
>> ping
>> a pre-defined
>> anycast address and expect back a unicast address for
>> discovering the unicast
>> address of a router e.g.? Ok, I see...
> Exact
more:
Some setup may use a ping to Subnet-Router anycast address and expect a reply to discover a unicast address (not very secure, but ...).
It is the reason why, I want to keep existing default.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-03 6:19 ` François-Xavier Le Bail
@ 2014-01-03 6:30 ` Hannes Frederic Sowa
2014-01-03 6:49 ` François-Xavier Le Bail
0 siblings, 1 reply; 12+ messages in thread
From: Hannes Frederic Sowa @ 2014-01-03 6:30 UTC (permalink / raw)
To: François-Xavier Le Bail
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
On Thu, Jan 02, 2014 at 10:19:24PM -0800, François-Xavier Le Bail wrote:
> On Fri, 1/3/14, François-Xavier Le Bail <fx.lebail@yahoo.com> wrote:
>
> --------------------------------------------
> On Thu, 1/2/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>
> >> Ah, I guess you are hinting at the situation where you
> >> ping
> >> a pre-defined
> >> anycast address and expect back a unicast address for
> >> discovering the unicast
> >> address of a router e.g.? Ok, I see...
>
> > Exact
>
> more:
> Some setup may use a ping to Subnet-Router anycast address and expect a reply to discover a unicast address (not very secure, but ...).
>
> It is the reason why, I want to keep existing default.
Yep, with pre-defined anycast address I actually meant the subnet router
anycast address. We currently don't need to deal with more than that one:
https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml
As soon as this patch gets applied, we have to keep the knob stable
in its semantic. So my proposal would be to change the knob to just
control the behaviour of ping replies and also change its name to reflect
this.
Leave datagram sending with specific anycast address as source just open and
don't protect it with this knob. Would that be a plan?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-03 6:30 ` Hannes Frederic Sowa
@ 2014-01-03 6:49 ` François-Xavier Le Bail
2014-01-03 7:04 ` Hannes Frederic Sowa
0 siblings, 1 reply; 12+ messages in thread
From: François-Xavier Le Bail @ 2014-01-03 6:49 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
On Fri, 1/3/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
On Thu, Jan 02, 2014 at 10:19:24PM -0800, François-Xavier Le Bail wrote:
>> Some setup may use a ping to Subnet-Router anycast
>> address and expect a reply to discover a unicast address
>> (not very secure, but ...).
>>
>> It is the reason why, I want to keep existing default.
> Yep, with pre-defined anycast address I actually meant the
> subnet router
> anycast address. We currently don't need to deal with more
> than that one:
> https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml
> As soon as this patch gets applied, we have to keep the knob stable
> in its semantic. So my proposal would be to change the knob to just
> control the behaviour of ping replies and also change its
> name to reflect this.
> Leave datagram sending with specific anycast address as
> source just open and
> don't protect it with this knob. Would that be a plan?
But service discovery may be done also with UDP, so I see the knob as a router policy:
It enable or not anycast source.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-03 6:49 ` François-Xavier Le Bail
@ 2014-01-03 7:04 ` Hannes Frederic Sowa
2014-01-03 7:09 ` Hannes Frederic Sowa
0 siblings, 1 reply; 12+ messages in thread
From: Hannes Frederic Sowa @ 2014-01-03 7:04 UTC (permalink / raw)
To: François-Xavier Le Bail
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy
On Thu, Jan 02, 2014 at 10:49:02PM -0800, François-Xavier Le Bail wrote:
> On Fri, 1/3/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
>
> On Thu, Jan 02, 2014 at 10:19:24PM -0800, François-Xavier Le Bail wrote:
>
> >> Some setup may use a ping to Subnet-Router anycast
> >> address and expect a reply to discover a unicast address
> >> (not very secure, but ...).
> >>
> >> It is the reason why, I want to keep existing default.
>
> > Yep, with pre-defined anycast address I actually meant the
> > subnet router
> > anycast address. We currently don't need to deal with more
> > than that one:
> > https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml
>
> > As soon as this patch gets applied, we have to keep the knob stable
> > in its semantic. So my proposal would be to change the knob to just
> > control the behaviour of ping replies and also change its
> > name to reflect this.
>
> > Leave datagram sending with specific anycast address as
> > source just open and
> > don't protect it with this knob. Would that be a plan?
>
> But service discovery may be done also with UDP, so I see the knob as a router policy:
> It enable or not anycast source.
Wouldn't distributions just enable this unconditionally and no one will ever
look at this option again?
IMHO it would be better if it could be controlled per application, because
they ultimately know how their discovery protocol works. In case of ping, it
is ok, because applications cannot control the source address here.
Greetings,
Hannes
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-03 7:04 ` Hannes Frederic Sowa
@ 2014-01-03 7:09 ` Hannes Frederic Sowa
2014-01-03 9:38 ` François-Xavier Le Bail
0 siblings, 1 reply; 12+ messages in thread
From: Hannes Frederic Sowa @ 2014-01-03 7:09 UTC (permalink / raw)
To: François-Xavier Le Bail, netdev, David S. Miller,
Alexey Kuznetsov, James Morris, Hideaki Yoshifuji,
Patrick McHardy
On Fri, Jan 03, 2014 at 08:04:26AM +0100, Hannes Frederic Sowa wrote:
> On Thu, Jan 02, 2014 at 10:49:02PM -0800, François-Xavier Le Bail wrote:
> > On Fri, 1/3/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> >
> > On Thu, Jan 02, 2014 at 10:19:24PM -0800, François-Xavier Le Bail wrote:
> >
> > >> Some setup may use a ping to Subnet-Router anycast
> > >> address and expect a reply to discover a unicast address
> > >> (not very secure, but ...).
> > >>
> > >> It is the reason why, I want to keep existing default.
> >
> > > Yep, with pre-defined anycast address I actually meant the
> > > subnet router
> > > anycast address. We currently don't need to deal with more
> > > than that one:
> > > https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml
> >
> > > As soon as this patch gets applied, we have to keep the knob stable
> > > in its semantic. So my proposal would be to change the knob to just
> > > control the behaviour of ping replies and also change its
> > > name to reflect this.
> >
> > > Leave datagram sending with specific anycast address as
> > > source just open and
> > > don't protect it with this knob. Would that be a plan?
> >
> > But service discovery may be done also with UDP, so I see the knob as a router policy:
> > It enable or not anycast source.
>
> Wouldn't distributions just enable this unconditionally and no one will ever
> look at this option again?
>
> IMHO it would be better if it could be controlled per application, because
> they ultimately know how their discovery protocol works. In case of ping, it
> is ok, because applications cannot control the source address here.
And actually, my preferred setup would be to use anycast addresses as source
addresses, but still have ping use the unicast address. This current patch
does not allow that?
Greetings,
Hannes
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses
2014-01-03 7:09 ` Hannes Frederic Sowa
@ 2014-01-03 9:38 ` François-Xavier Le Bail
0 siblings, 0 replies; 12+ messages in thread
From: François-Xavier Le Bail @ 2014-01-03 9:38 UTC (permalink / raw)
To: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki Yoshifuji, Patrick McHardy, Hannes Frederic Sowa
--------------------------------------------
On Fri, 1/3/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> And actually, my preferred setup would be to use anycast
> addresses as source
> addresses, but still have ping use the unicast address. This
> current patch
> does not allow that?
No, I will send separate patches for echo reply and datagrams.
Francois-Xavier
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-01-03 9:44 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-02 18:56 [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses François-Xavier Le Bail
2014-01-02 23:17 ` Hannes Frederic Sowa
2014-01-02 23:19 ` Hannes Frederic Sowa
2014-01-03 5:58 ` François-Xavier Le Bail
2014-01-03 6:19 ` François-Xavier Le Bail
2014-01-03 6:30 ` Hannes Frederic Sowa
2014-01-03 6:49 ` François-Xavier Le Bail
2014-01-03 7:04 ` Hannes Frederic Sowa
2014-01-03 7:09 ` Hannes Frederic Sowa
2014-01-03 9:38 ` François-Xavier Le Bail
-- strict thread matches above, loose matches on Subject: below --
2014-01-02 15:53 Francois-Xavier Le Bail
2014-01-02 17:17 ` Hannes Frederic Sowa
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).