Pascal Hambourg a écrit :
In practice, things are not that simple. The 'route information' option is not part of the original Router Discovery specification, so older IPv6 implementations may not support it. Linux supports it since version 2.6.17 if configuration option IPV6_ROUTE_INFO is enabled, but it is functionnally disabled by default because the sysctl parameters net.ipv6.conf.*.accept_ra_rt_info_max_plen which defines the maximum prefix length of accepted route information is set to 0 by default. In order to accept a route for a /64 prefix, you must set it to at least 64. In Debian it can be set at startup for all interfaces by appending the following line in /etc/sysctl.conf, assuming that the 'ipv6' module has been loaded before (.e.g. by adding it in /etc/modules), otherwise the parameter won't exist yet :net.ipv6.conf.default.accept_ra_rt_info_max_plen=64
Hmm, looks like this is may not work with a kernel 2.6.21 or later because entries for interfaces in net.ipv6.conf are created as soon as the interface is created, whereas older kernels used to create the entry in net.ipv6.conf only when the interface goes UP for the first time. So it might be necessary to add net.ipv6.conf.<interface>.accept_ra_rt_info_max_plen=64 too.
Note :A similar change was applied to IPv4 interface parameters in net.ipv4.conf too. However I observed that changing a parameter value in net.ipv4.conf.default immediately applies to all interfaces which are not UP, which may preserve the previous behaviour. Unfortunately this does not work for IPv6 parameters.
If an ethernet host ignores the route information in RAs, it will send packets for the wireless prefix to the default router, (1). Router (1) will forward the packets to router (2). It should also send an ICMPv6 Redirect to tell the host that there is a better route to the prefix. However I tested this scenario on my Debian router with 2.6.24 kernel and didn't see it sending ICMPv6 Redirects, although it forwarded the packets back on the same interface as expected.
I think I got it. The RFC 4861 says that the redirect target address must be the link-local address of the next-hop router, but I had used the global address of the router in the route. When using the link-local address instead, the router sends ICMPv6 redirects.