<div dir="ltr">Fascinating. My test system, which I had believed was in compliance with the current STIG, has <div><br></div><div>options ipv6 disable=1</div><div><br></div><div> in a /etc/modprobe.d file... Time to relook at this, then!<div>

<br></div><div style>Perhaps this is why bonding is somewhat flaky on this system. Humph. </div></div><div style><br></div><div style>It sounds like it&#39;s coming live to my environment, so I get to include more tests in my reports. Progress. I&#39;ll work through this one too.</div>

<div style><br></div><div style>Thanks again! All kinds of good information!</div><div style><br></div><div style>Andrew</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 3:50 PM, Steve Grubb <span dir="ltr">&lt;<a href="mailto:sgrubb@redhat.com" target="_blank">sgrubb@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tuesday, March 25, 2014 03:32:48 PM Andrew Gilmore wrote:<br>
&gt; &gt; Put another way, its not that IPv6 is insecure...its very well tested. Its<br>
&gt; &gt; that if you don&#39;t need it or use it and a security bulletin comes along<br>
&gt; &gt; for it, its easy to dismiss because you didn&#39;t intend to use it.<br>
&gt;<br>
&gt; This was part of my real question, I guess. Much of what I had heard about<br>
&gt; IPV6 focused on the relative maturity of the stack, compared to IPV4, and<br>
&gt; suggested that some of the same types of critical vulnerabilities that we<br>
&gt; saw in the 90s may be lurking in this stack. It&#39;s good to hear your<br>
&gt; confidence in the tech.<br>
<br>
</div>Let me explain a bit. In the first draft of the SNAC guide, I think it said<br>
something like to disable do<br>
<br>
install ipv6 /bin/true<br>
<br>
This worked back in 2008 because IPv6 and IPv4 were separate. There was not<br>
much overlap in code. However, things progress over the years and people<br>
wondered why they have to make bug fixes to 2 independent code paths when a lot<br>
could be shared. At this point, if you tried to do the above method for<br>
disabling IPv6, you&#39;d find the following broken:<br>
<br>
 - bridging<br>
 - bonding<br>
 - ebtables<br>
 - various iSCSI drivers<br>
 - infiniband<br>
 - assorted bits of netfliter<br>
<br>
Additionally, routing information, ARP entries, and ipv6 specific device state<br>
are shared between modules. So, there really is a lot of &quot;ipv6&quot; code running<br>
on a &quot;ipv4&quot; system. In light of this, the way of turning of IPv6 had to change<br>
because of the shared code base. We now recommend<br>
<br>
CONFIG_IPV6=n<br>
<br>
because ipv6 must be loaded because it does get used. i was told that 1/2 of<br>
the IPv6 codebase is shared with IPv4.<br>
<br>
To circle back to the beginning, So, why turn it off at all? Because the other<br>
half of the IPv6 stack is not used all the time and eliminating lines of code<br>
helps harden the system.<br>
<span class="HOEnZb"><font color="#888888"><br>
Steve<br>
</font></span></blockquote></div><br></div>