On 2014-04-28 10:45, Rogier Wolff wrote: > On Mon, Apr 28, 2014 at 09:43:40AM +0200, Jeroen Massar wrote: >> Note that there are a variety of forums that are a much better place >> than a Debian mtr package bug report for these kind of questions. > > I'm not asking for help. I'm trying to communicate that I think that > disabling IPV6 is a valid configuration. > > I fully agree with the decisions "upstream" in debian to enable > IPV6. But you should respect those that may have reasons to disable > it.
But then you should not expect everything to 'just work'. In the same way, that some people want to disable IPv4, which in the current Linux kernel cannot work. [..] >> Unless somebody sets up a router advertisement to announce a prefix (for >> which they need local access to the network), your host will only have a >> link-local (fe80::/10) address, which means the adversary has local >> access to your network. > > I could look this up in under 60 seconds. But I haven't. You might want to; uninformed comments are not nicely accepted by most people and tend to get ignored. If you can't bother to spend time, then don't waste that of other people. See https://en.wikipedia.org/wiki/Link-local_address for the details about link-locals. > So when my machine asks for an IPV6 address on the link it gets one. > If I'd look it up I'd see it was a link-local address. I'm guessing > similar to the 192.168.x.y that I'm using for IPV4 that they won't > work outside my home network. Similar to 169.254.0.0/16 actually. Indeed, link-locals are not routable (and NATting them is in IPv6 quite tricky to, as some networks stacks really do not route them and set the TTL of packets to 1 to enforce that). > So how do I know that when I boot tomorrow my machine won't get a > routable IPV6 address? I don't. Not if you cannot trust your local network indeed. But the problem there is that you are trusting your local network. Simple solution to all of it: install a IPv6 firewall: ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT ip6tables -A OUTPUT -j REJECT [..] > The "we need to switch to IPV6 NOW" crowd lost credibility with me > when they announced "we'll have serious trouble in XXX time when we'll > run out of IPV4 addresses". This was announced three years in a row, > with XXX always less than 12 months. I haven't heard about the IPV4 > addresses running out for about a year now. Is the new announcement > going out soon, or did I miss one? Only this crucial one a few days ago: https://www.arin.net/announcements/2014/20140423.html Note that the other RIRs are already running on fumes for IPv4 for much longer... Those warnings are there to warn people to get their game up and finally do something. If you start now, you (or the companies/organisations/etc you hear from) are late. >>> The little I know about IPV6 is that there won't be a need to >>> "masquerade" like we do now. Well, that masquerading is part of my >>> security strategy. >> >> The part that 'masquerading' adds in your 'security strategy' is >> connection tracking. Not the actual act of translating addresses; they >> actually make your box wide open. > > The masquerading part helps my security: My machine thinks its address > is 192.168.x.y, and besides people on or very close to my network, > nobody will be able to get packets with that addres to travel to my > machine. You are oh so wrong. > What is "they" referring to in "they actually make..."? they = "The mechanism of NAT / masquerading" > You're saying that masquerading makes my machine wide open? Bingo. It is no more "secure" than putting it directly on the network. See amongst others http://samy.pl/pwnat/ > Are you following the microsoft tactic that OUTgoing connections need > to be firewalled? No. Because if something is able to make an outgoing connection the game is already lost as somebody is on the machine already. > Sure. On my phone I install apps that should not be > connecting to the internet on a whim. But on my PC I'm more afraid of > the 4 billion internet-users out there, one of which might try to > connect to a service on my machine. At the moment that "try to > connect" they are now blocked because I don't have a routable internet > address. As you perform NAT, it does have a *reachable* address though. See the pwnat above for the details. >>> I know that my machines, when running a recent distribution, obtain an >>> IPV6 address. If my home router suddenly started giving my home >>> machines routable IPV6 addresses that would break my "fence". >> >> If you do not trust machines connection to your local network then you >> should fix that hole in the fence. > > My provider will, at some time between 2010 and 2020 decide to enable > IPV6 to their clients. I don't want to have to be there at the moment > they decide to enable it. Then install a firewall. >>> So... best thing to do is to make sure my machine will never talk >>> IPV6. How about I compile a kernel without IPV6? Or maybe just boot >>> with ipv6disable=1? >> >> Instead of disabling IPv6, just firewall it: >> >> ip6tables -A INPUT -j REJECT >> ip6tables -A FORWARD -j REJECT > > There is more than one way to skin a cat. And that is the proper way to do it. It addresses your concerns fully. > If you think that an outgoing connection that goes through > masquerading is a security risk, will you permit me to consider ipv6 > enabled, but firewalled a risk? No. As that is not a risk (unless of course there is a bug in the network stack, but when that is the case, you have lost already anyway). The bigger problem in your setup is that you seem to trust the local network, but then do not trust them to do the right thing. That combination does not fly. Either way, just firewalling it solves it all. > To be able to issue the above commands I've had to learn that the > command for ipv6 firewallin is ip6tables. You've just told me. > What if I stumbled on the "disable IPV6 altogether" solution first? Your problem, as you are causing problems for yourself. That is what this ticket is about: you caused a problem, as the tool expects there to be IPv6 support, even if it won't use it. > Your "firewall all IPV6" solution means that applicaitons on my > machine continue to think that IPV6 is available, and then fail to > make a connection or take seconds before they timeout the attempt to > make the IPV6 connection. They do not take seconds to timeout, hence why there is a REJECT. But indeed, the application might think that there is IPv6 while there is not. >> More importantly though: it is 2014, IPv6 has been available to the >> general public for almost 20 years (6bone is from 1996-ish). Use it. > > I do some things with the argument "because it's there". But "ipv6" is > not one of those things. My only answer to that is: You are living in a cave when you think IPv6 is not there... Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
