netdev - Re: linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <OFEC88F859.86FF615D-ON88257719.005D5A0F-88257719.005DDE16@us.ibm.com>
Date:	Tue, 4 May 2010 10:05:16 -0700
From:	David Stevens <dlstevens@...ibm.com>
To:	Brian Haley <brian.haley@...com>
Cc:	David Miller <davem@...emloft.net>, enh@...gle.com,
	netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: linux kernel's IPV6_MULTICAST_HOPS default is 64; should be 1?

 > Yes, that would be the ideal fix, and give the admin more control over
> the value, but it seems like overkill to me.  It's been 64 for a while,
> and it's always been changeable by apps.  I guess the only thing to
> think about is there could be an app that works because it being 64
> today, but will break tomorrow.  Having a tunable parameter will let
> you get the app working without re-writing it.

        Well, it should've been 1, and any app relying on having
multicast routing really should set it explicitly.
        I think per-interface defaulting to 1 should be ok. I'd
prefer carrying the "-1" so apps that set it get what they want
and apps that don't carry the current default, rather than the
value at the time the socket was created, but practically it probably
doesn't matter. In reality, apps that need more than one will
already be setting it to a non-default value.

                                                        +-DLS

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