Structure icmp6hdr (IPv6/ICMPv6) with bug in the bitfields!

First, let-me say sorry for the long text, i think is needed for
context.

My name is Pedro Ribeiro and I’m the operations coordinator at
IPLNet, a network that interconnects all the schools belonging to the
Polytechnic Institute of Lisbon (IPL) and in addition I’m also a
teacher of network engineering at ISEL (a local university).

In the majority of the network segments of our infrastructure, we
have dual stack connectivity with IPv4/IPv6. In the last months, we
have upgraded most of the infrastructure, specially targeting IPv6
performance leaving most of the segments with an “old/slow router” and
a “new/fast” router as possible default gateways.
In the course of validating the changes, we have done some tests with
IPv6 and some of them were really disappointing with no gains at all.

While investigating the cause of that, I have seen that our main
Linux servers were using the “wrong” default gateway, the “old/slow”
one. This behaviour is inconsistent with the configuration of the
routers; the “new/fast” is sending the router advertisements
announcing himself as default gateway with MEDIUM (default) preference
and the “old/slow” announcing himself as LOW preference.

Deep analysis in the sources of Linux revealed that the value of
“pref” passed to rt6_add_dflt_router(...) in the file net/ipv6/route.c
isn’t consistent with the one sent by the routers and observed with
wireshark. Seeking the roots of the problem I’ve detected a bug in the
definitions of the bitfield that includes the router preference in the
router advertisement message that are resulting in retrieving the
wrong bits from the structure defined in “include/linux/icmpv6.h”. The
struct is the base one from ICMPv6 (icmp6hdr) and was lacking the bit
field “home_agent” between “router_pref” and “other” and the reserved
bits are only 3, not 4 as in the structure (according to RFC4191)

Follows a “diff” with the changes I’ve made to correct this problem
(I’ve made it against kernel 2.6.23, but I’ve confirmed that the
problem still exists in 2.6.25)


Even after this fix, the problem of deterministic and preference
aware default route selection, remains. I have not figured until now
how the preference affects the selection, maybe it is a missing
feature.

I am sorry to say it (I am not a Windows fan), but the behaviour
observed in Windows Vista is in this matter consistent with the one I
was expecting from the reading of the RFCs.

Developers on this area please clarify me this subject; does the
preference present in the RAs is supposed to influence the decision?
In addition, what is the criterion for selecting the default route in
the presence of multiple candidates with the same preference?
Best Regards to all the Linux community!

Hi,

Pedro Ribeiro <pribeiro-bulk@net.ipl.pt> writes:

> Deep analysis in the sources of Linux revealed that the value of
> “pref” passed to rt6_add_dflt_router(...) in the file net/ipv6/route.c
> isn’t consistent with the one sent by the routers and observed with
> wireshark. Seeking the roots of the problem I’ve detected a bug in the
> definitions of the bitfield that includes the router preference in the
> router advertisement message that are resulting in retrieving the
> wrong bits from the structure defined in “include/linux/icmpv6.h”. The
> struct is the base one from ICMPv6 (icmp6hdr) and was lacking the bit
> field “home_agent” between “router_pref” and “other” and the reserved
> bits are only 3, not 4 as in the structure (according to RFC4191)

+1

> Follows a “diff” with the changes I’ve made to correct this problem
> (I’ve made it against kernel 2.6.23, but I’ve confirmed that the
> problem still exists in 2.6.25)
>
> --- /usr/src/linux-2.6.23-gentoo-r9orig/include/linux/icmpv6.h      2007-10-09 21:31:38.000000000 +0100
> +++ /usr/src/linux-2.6.23-gentoo-r9/include/linux/icmpv6.h      2008-10-13 17:42:56.000000000 +0100
> @@ -40,16 +40,18 @@
>                  struct icmpv6_nd_ra {
>                         __u8            hop_limit;
>  #if defined(__LITTLE_ENDIAN_BITFIELD)
> -                       __u8            reserved:4,
> +                       __u8            reserved:3,
>                                         router_pref:2,
> +                                       home_agent:1,
>                                         other:1,
>                                         managed:1;
>  
>  #elif defined(__BIG_ENDIAN_BITFIELD)
>                         __u8            managed:1,
>                                         other:1,
> +                                       home_agent:1,
>                                         router_pref:2,
> -                                       reserved:4;
> +                                       reserved:3;
>  #else
>  #error "Please fix <asm/byteorder.h>"
>  #endif

Changes look ok to me.

> Even after this fix, the problem of deterministic and preference
> aware default route selection, remains. I have not figured until now
> how the preference affects the selection, maybe it is a missing
> feature.

can you confirm that you already activated CONFIG_IPV6_ROUTER_PREF in
your kernel configuration?

What are the values of following parameters on your system?:

  /proc/sys/net/ipv6/conf/*/accept_ra_rtr_pref
  /proc/sys/net/ipv6/conf/*/accept_ra_pinfo
  /proc/sys/net/ipv6/conf/*/accept_ra
  /proc/sys/net/ipv6/conf/*/autoconf

> Developers on this area please clarify me this subject; does the
> preference present in the RAs is supposed to influence the decision?

Looking at the code in ndisc.c (ndisc_router_discovery()), it should,
but I may have missed something.

> In addition, what is the criterion for selecting the default route in
> the presence of multiple candidates with the same preference?

Don't know.

Funny it was not detected sooner. In patches I have for UMIP (userland
MIPv6 Daemon for Linux), access to router preferences field is done by
shifting bits (correctly, AFAICT) and routes are set from userspace
using that info. radvd also fills its RA that way, i.e. by shifting bits
(it uses struct nd_router_advert from netinet/icmp6.h, which does not
have anything for router preference). That would explain why I never hit
the bug.

Cheers,

a+

ps: added YOSHIFUJI Hideaki in CC.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello Arnaud,

Thanks for your quick answer ...

Here goes the information solicited.

TIA.

Tuesday, October 14, 2008, 1:58:41 PM, you wrote:

...

> can you confirm that you already activated CONFIG_IPV6_ROUTER_PREF in
> your kernel configuration?

host ~ # gzip -d -c /proc/config.gz | grep -F CONFIG_IPV6_ROUTER_PREF
CONFIG_IPV6_ROUTER_PREF=y

> What are the values of following parameters on your system?:

>   /proc/sys/net/ipv6/conf/*/accept_ra_rtr_pref
>   /proc/sys/net/ipv6/conf/*/accept_ra_pinfo
>   /proc/sys/net/ipv6/conf/*/accept_ra
>   /proc/sys/net/ipv6/conf/*/autoconf

All of them have value "1"

/proc/sys/net/ipv6/conf/all/accept_ra:1
/proc/sys/net/ipv6/conf/all/accept_ra_defrtr:1
/proc/sys/net/ipv6/conf/all/accept_ra_pinfo:1
/proc/sys/net/ipv6/conf/all/accept_ra_rtr_pref:1
/proc/sys/net/ipv6/conf/default/accept_ra:1
/proc/sys/net/ipv6/conf/default/accept_ra_defrtr:1
/proc/sys/net/ipv6/conf/default/accept_ra_pinfo:1
/proc/sys/net/ipv6/conf/default/accept_ra_rtr_pref:1
/proc/sys/net/ipv6/conf/eth0/accept_ra:1
/proc/sys/net/ipv6/conf/eth0/accept_ra_defrtr:1
/proc/sys/net/ipv6/conf/eth0/accept_ra_pinfo:1
/proc/sys/net/ipv6/conf/eth0/accept_ra_rtr_pref:1
/proc/sys/net/ipv6/conf/lo/accept_ra:1
/proc/sys/net/ipv6/conf/lo/accept_ra_defrtr:1
/proc/sys/net/ipv6/conf/lo/accept_ra_pinfo:1
/proc/sys/net/ipv6/conf/lo/accept_ra_rtr_pref:1
/proc/sys/net/ipv6/conf/all/autoconf:1
/proc/sys/net/ipv6/conf/default/autoconf:1
/proc/sys/net/ipv6/conf/eth0/autoconf:1
/proc/sys/net/ipv6/conf/lo/autoconf:1

Best regards.

From: Pedro Ribeiro <pribeiro-bulk@net.ipl.pt>

Date: Tue, 14 Oct 2008 12:06:20 +0100

> Follows a “diff” with the changes I’ve made to correct this problem

> (I’ve made it against kernel 2.6.23, but I’ve confirmed that the

> problem still exists in 2.6.25)


Please make your patch against current sources, it does not apply
to the current tree.