Re: Is there a way to stop ipv6 leakage without turning off ipv6?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/7/17 10:17 AM, Rick Stevens wrote:
On 04/06/2017 02:45 PM, Stephen Morris wrote:
On 4/6/17 9:20 AM, Ed Greshko wrote:
On 04/06/17 06:57, Stephen Morris wrote:
Hi Ed, just as a side issue to this, because my ISP (I don't know
about my VPN provider) IPv6 at all for anything, I was setting IPv6 to
'ignore' via Networkmanager in KDE (Gnome doesn't seem to have the
same options) but that was causing messages in the logs at boot time
about IPv6 not being ready. How do we stop the network from attempting
to activate IPv6 and then producing these messages when it has been
turned off?
(We inadvertently went off list...So I will reproduce what I sent Steve
here)

Early AM here in Taiwan.  No coffee yet.

I think you are saying your ISP isn't providing IPv6 support at all and
that you'd like to totally disable IPv6.  If that is the case then you
can do this by adding ipv6.disable=1 to the kernel boot parameters in
grub.

If I misunderstood your question let me know and I'll try again after
coffee.

Later, with still no coffee.....

I decided to do a test and add ipv6.disable=1 to the kernel parameter on
one of my VM's.  In the past, this was sufficient.  However, doing only
this now results in selinux errors.  To avoid those you also need to add
"net.ipv6.conf.all.disable_ipv6 = 1" to /etc/sysctl.conf.
Your assessment was correct Ed. I meant to say that my ISP doesn't
support IPv6 at all.

Instead of setting the IPv6 options to 'Ignore' in the networkmanager
definition for my router, I have set the option to 'Link-local', which
has also stopped the boot time messages. What exactly does 'Link-local'
actually do (my assumption was it has activated IPv6 addressing for
local network routing but not activated IPv6 for internet routing)?
Uhm, sorta. A link-local address means those IPs will only be used
in the local LAN segment and should not attempt to traverse gateways.

Link-local addresses are actual IP addresses. In IPV4, the allowed
addresses are inside the 169.254.1.0 - 169.254.254.255 range (note that
this is almost, but not quite the CIDR 169.254.0.0/16) but are NOT
mandatory.  In IPV4, if you have a valid IPV4 address, that's good
enough for everything.

NOTE: The link-local IPV4s look like they're routable since they're not
in the private IP networks 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.
Since routers will not pass those link-local IPs along, they're really
not routable.

For IPV6, link-local addresses are in fe80::/10 (to conform to /64
requirements on LAN segments, it's often called fe80::/64) and ARE
mandatory (used for things like DHCPV6 and NDP). Unlike IPV4, IPV6
_requires_ every interface to have (at least) a link-local address. If
the IPV6 interface is externally routable, it will require a second
IPV6 IP which is used for the external routes, so most IPV6 interfaces
you see will have two (or more) addresses associated with them.

Confusing, ain't it? My brain starts to bleed every time I get into this
stuff. Grumph!
Thanks Rick, am I correct in understanding that you are saying that even though I have IPv6 set to link-local, that IPv6 is still being attempted across the internet gateway, and in my case because my ISP doesn't support IPv6, I am assuming those packets would be rejected and hence the system would fall back to IPv4, or is it the case that IPv6 is tried for every transmission, which would then make internet access horribly inefficient?

regards,
Steve

----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks@xxxxxxxxxxxxxx -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-     To get that bulldozer airborne, we need more explosives.       -
-                                                -- Jamie Hyneman    -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux