Tonnerre LOMBARD <tonnerre%netbsd.ch@localhost> wrote
in <20090712221139.GJ6410%jules.pas-un-geek-en-tant-que-tel.ch@localhost>:
to> Salut,
to>
to> On Mon, Jul 13, 2009 at 06:36:22AM +0900, Hiroki Sato wrote:
to> > I don't think adding a new flag is reasonable because there is a
to> > per-interface flag to control accepting RA (ND6_IFF_ACCEPT_RTADV)
to> > already.
to>
to> How would one set that flag? I've only seen it being set in one
to> single place which had no attachment whatsoever to any type of
to> logic.
Can be set by using ndp(8) and the flag is used in nd6_ra_input().
I fully agree with your idea and having such a per-interface flag is
the way to go since accepting RAs should be controlled in that way on
a system with multiple interfaces. It is supposed that
ND6_IFF_ACCEPT_RTADV can be used, not by adding a protocol-dependent
flag to struct ifnet (we should avoid it if we can) , but we need
some more change because it is not fully implemented.
Actually I have a similar patchset to yours in another way:
1) Add a part of ndp(8) functionality to ifconfig(8). We have the
ndp(8) utility for changing IPv6 NDP parameters but it is more
reasonable that the per-interface parameters are handled by
ifconfig(8) for consistency. More specifically, PERFORMNUD,
ACCEPT_RTADV, DISABLED, and default interface (ndp -I) should be
done by ifconfig(8) like "ifconfig le0 inet6 -accept_rtadv".
2) Use the existing sysctl net.inet6.ip6.accept_rtadv as the default
value of the corresponding per-IF flags, not a global knob. The
accept_rtadv is set as 0 by default.
3) Add (ip6.fowarding == 0 && ND6_IFF_ACCEPT_RTADV) check to
nd6_ra_input(). The other similar checks for if the node is
router or if the interface has ND6_IFF_ACCEPT_RTADV have been made
consistent wherever possible. Especially when (ip6.forwarding ==
1) is true, ignore RAs regardless of ND6_IFF_ACCEPT_RTADV.
4) Remove IPV6CTL_ACCEPT_RTADV check in rtsold(8).
What do you think of this way? I am using the patchset against a bit
old source tree for some time. I can send it to you for the latest
source tree in a couple of days.
-- Hiroki
Attachment:
pgprT0_VKGFCd.pgp
Description: PGP signature