89225d1ce6
i) RFC3810, 9.2. Query Interval [QI] says: The Query Interval variable denotes the interval between General Queries sent by the Querier. Default value: 125 seconds. [...] ii) RFC3810, 9.3. Query Response Interval [QRI] says: The Maximum Response Delay used to calculate the Maximum Response Code inserted into the periodic General Queries. Default value: 10000 (10 seconds) [...] The number of seconds represented by the [Query Response Interval] must be less than the [Query Interval]. iii) RFC3810, 9.12. Older Version Querier Present Timeout [OVQPT] says: The Older Version Querier Present Timeout is the time-out for transitioning a host back to MLDv2 Host Compatibility Mode. When an MLDv1 query is received, MLDv2 hosts set their Older Version Querier Present Timer to [Older Version Querier Present Timeout]. This value MUST be ([Robustness Variable] times (the [Query Interval] in the last Query received)) plus ([Query Response Interval]). Hence, on *default* the timeout results in: [RV] = 2, [QI] = 125sec, [QRI] = 10sec [OVQPT] = [RV] * [QI] + [QRI] = 260sec Having that said, we currently calculate [OVQPT] (here given as 'switchback' variable) as ... switchback = (idev->mc_qrv + 1) * max_delay RFC3810, 9.12. says "the [Query Interval] in the last Query received". In section "9.14. Configuring timers", it is said: This section is meant to provide advice to network administrators on how to tune these settings to their network. Ambitious router implementations might tune these settings dynamically based upon changing characteristics of the network. [...] iv) RFC38010, 9.14.2. Query Interval: The overall level of periodic MLD traffic is inversely proportional to the Query Interval. A longer Query Interval results in a lower overall level of MLD traffic. The value of the Query Interval MUST be equal to or greater than the Maximum Response Delay used to calculate the Maximum Response Code inserted in General Query messages. I assume that was why switchback is calculated as is (3 * max_delay), although this setting seems to be meant for routers only to configure their [QI] interval for non-default intervals. So usage here like this is clearly wrong. Concluding, the current behaviour in IPv6's multicast code is not conform to the RFC as switch back is calculated wrongly. That is, it has a too small value, so MLDv2 hosts switch back again to MLDv2 way too early, i.e. ~30secs instead of ~260secs on default. Hence, introduce necessary helper functions and fix this up properly as it should be. Introduced in 06da92283 ("[IPV6]: Add MLDv2 support."). Credits to Hannes Frederic Sowa who also had a hand in this as well. Also thanks to Hangbin Liu who did initial testing. Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Cc: David Stevens <dlstevens@us.ibm.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
netfilter | ||
addrconf_core.c | ||
addrconf.c | ||
addrlabel.c | ||
af_inet6.c | ||
ah6.c | ||
anycast.c | ||
datagram.c | ||
esp6.c | ||
exthdrs_core.c | ||
exthdrs_offload.c | ||
exthdrs.c | ||
fib6_rules.c | ||
icmp.c | ||
inet6_connection_sock.c | ||
inet6_hashtables.c | ||
ip6_checksum.c | ||
ip6_fib.c | ||
ip6_flowlabel.c | ||
ip6_gre.c | ||
ip6_icmp.c | ||
ip6_input.c | ||
ip6_offload.c | ||
ip6_offload.h | ||
ip6_output.c | ||
ip6_tunnel.c | ||
ip6mr.c | ||
ipcomp6.c | ||
ipv6_sockglue.c | ||
Kconfig | ||
Makefile | ||
mcast.c | ||
mip6.c | ||
ndisc.c | ||
netfilter.c | ||
output_core.c | ||
ping.c | ||
proc.c | ||
protocol.c | ||
raw.c | ||
reassembly.c | ||
route.c | ||
sit.c | ||
syncookies.c | ||
sysctl_net_ipv6.c | ||
tcp_ipv6.c | ||
tcpv6_offload.c | ||
tunnel6.c | ||
udp_impl.h | ||
udp_offload.c | ||
udp.c | ||
udplite.c | ||
xfrm6_input.c | ||
xfrm6_mode_beet.c | ||
xfrm6_mode_ro.c | ||
xfrm6_mode_transport.c | ||
xfrm6_mode_tunnel.c | ||
xfrm6_output.c | ||
xfrm6_policy.c | ||
xfrm6_state.c | ||
xfrm6_tunnel.c |