Hi all,
Once in a while I see people suggesting the disabling of IPv6 to cope with some issue.
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
Lately I read a message on another M.L. from someone who only gets an IPv6 address from his provider, and gets his connection to legacy sites by means on 4in6 tunneling.
On behalf of those people, "disabling v6" simply means: switch of your entire network. If an application / service cannot cope with v6, the solution should be with that application, not by mutilating the network stack ;-)
Kind regards, Hans
______________________________________________________________________ Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.
Am 09.07.2013 10:58, schrieb J.Witvliet@mindef.nl:
Hi all,
Once in a while I see people suggesting the disabling of IPv6 to cope with some issue.
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
Lately I read a message on another M.L. from someone who only gets an IPv6 address from his provider, and gets his connection to legacy sites by means on 4in6 tunneling.
On behalf of those people, "disabling v6" simply means: switch of your entire network. If an application / service cannot cope with v6, the solution should be with that application, not by mutilating the network stack ;-)
may i _kindly_ ask to give a relieable way like ipv6.disable=1 which works in F17/F18 and not in F19 beause i know what i am doing and there is currently no need for ipv6
the "inet6 ::1 prefixlen 128 scopeid 0x10<host>" means i need as example to run ip6tables to block access on servers to localhost:139/445 because internally the machine is serviced via SMB instead FTP but a PHP-script must never open a socket to the samba daemon
On Tue, 9 Jul 2013 10:58:59 +0200 J.Witvliet@mindef.nl wrote:
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
My main symptom is the single longest delay during the mostly zippy boot is bringing up the network where it appears to be expecting to be given an IPv6 address and times out eventually after not getting one.
I have certainly been tempted to disable ipv6 just to find out if that really is the source of the delay.
On Tue, 2013-07-09 at 10:58 +0200, J.Witvliet@mindef.nl wrote:
Once in a while I see people suggesting the disabling of IPv6 to cope with some issue.
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
In my case, I have a completely IPv4 network, and a complete impossibility to do IPv6 over the internet (I'd need an IP6 to 4 proxy *OUTSIDE* of my ISP). So...
(a) It's useless on my network.
(b) I have seen things fail/annoyingly-delay where they tried IPv6 first, waited, then tried IPv4, because...
(I) The machine had an IPv6 address, so things erroneosly presume that they can do IPv6 networking.
(II) DNS lookups can return IPv6 addresses, which it did.
(c) I see no point having to configure something that cannot actually be used (in my case).
(d) I'd like to see the computer realise that when the DHCP server, nor anything else, is not giving it a IPv6 address, automatically disable IPv6 on the computer. Not invent a useless IPv6 address for itself that causes other problems.
Hi,
On Tue, 2013-07-09 at 10:58 +0200, J.Witvliet@mindef.nl wrote:
Once in a while I see people suggesting the disabling of IPv6 to cope with some issue.
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
In my case, I have a completely IPv4 network, and a complete impossibility to do IPv6 over the internet (I'd need an IP6 to 4 proxy *OUTSIDE* of my ISP). So...
Somtimes we techinicians give advice based on an ideal world. :-) But on the real world disabling IPv6 everywhere is the *right* thing to do for many companies. if you don't have the need, don't have the knowledge and your hardware/software doesn't support it well, IPv6 is not only overhead with no added value but also may present a significant security risk. Just like you should disable any system service (specially network services) that you don't need to reduce a hacker attack surface on your network and servers.
[]s, Fernando Lozano
On 07/09/2013 02:27 PM, Fernando Lozano wrote:
Hi,
On Tue, 2013-07-09 at 10:58 +0200, J.Witvliet@mindef.nl wrote:
Once in a while I see people suggesting the disabling of IPv6 to cope with some issue.
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
In my case, I have a completely IPv4 network, and a complete impossibility to do IPv6 over the internet (I'd need an IP6 to 4 proxy *OUTSIDE* of my ISP). So...
Somtimes we techinicians give advice based on an ideal world. :-) But on the real world disabling IPv6 everywhere is the *right* thing to do for many companies. if you don't have the need, don't have the knowledge and your hardware/software doesn't support it well, IPv6 is not only overhead with no added value but also may present a significant security risk. Just like you should disable any system service (specially network services) that you don't need to reduce a hacker attack surface on your network and servers.
[]s, Fernando Lozano
Good advice Fernando! even though I don't have IPV6 running anywhere on my home network, my SISTER does, and I'm sure there are times when she'll be tempted to do just as you said to alleviate some problem or other...
EGO II
On Jul 9, 2013 1:59 PM, "Eddie G. O'Connor Jr." eoconnor25@gmail.com wrote:
On 07/09/2013 02:27 PM, Fernando Lozano wrote:
Hi,
On Tue, 2013-07-09 at 10:58 +0200, J.Witvliet@mindef.nl wrote:
Once in a while I see people suggesting the disabling of IPv6 to cope with some issue.
My I _kindly_ ask not to do that anymore? Even though such trick might take away the symptoms for you and me, it is a technical overkill and only tackles the symptoms.
In my case, I have a completely IPv4 network, and a complete impossibility to do IPv6 over the internet (I'd need an IP6 to 4 proxy *OUTSIDE* of my ISP). So...
Somtimes we techinicians give advice based on an ideal world. :-) But on the real world disabling IPv6 everywhere is the *right* thing to do for many companies. if you don't have the need, don't have the knowledge and your hardware/software doesn't support it well, IPv6 is not only overhead with no added value but also may present a significant security risk. Just like you should disable any system service (specially network services) that you don't need to reduce a hacker attack surface on your network and servers.
[]s, Fernando Lozano
Good advice Fernando! even though I don't have IPV6 running anywhere on my home network, my SISTER does, and I'm sure there are times when she'll be tempted to do just as you said to alleviate some problem or other...
EGO II
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Is it possible to give the end-user the option whether to go IVP4 or IPV6?
Hi,
disabling IPv6 everywhere is the *right* thing to do for many companies. if you don't have the need, don't have the
knowledge and
your hardware/software doesn't support it well, IPv6 is not only overhead with no added value but also may present a significant
security
risk. Just like you should disable any system service (specially
network
services) that you don't need to reduce a hacker attack surface on
your
network and servers.
Is it possible to give the end-user the option whether to go IVP4 or IPV6?
I haven't found yet an OS clearly showing how to disable IPv6 in a way most non-techinical users can find. But all them have this option somewhere, alongside other "esotheric" options like level 2 security.
Given IPv6 current state, where many vulnerabilities are related to autoconfiguration for home and small networks, and given the fact many ISPs still doesn't support IPv6 at all, IMHO the default setting should be IPv6 disabled. Any end user or sysadmin should take action only to enable IPv6, not to remove the threads it represents today.
Actually having IPv6 enabled by default is against security best practices. But even security experts forget this because everyone wants to lobby for broader IPv6 adoption. The end user pays the price for technologican evolution.
[]s, Fernando Lozano
Fernando Lozano wrote:
Given IPv6 current state, where many vulnerabilities are related to autoconfiguration for home and small networks, and given the fact many ISPs still doesn't support IPv6 at all, IMHO the default setting should be IPv6 disabled. Any end user or sysadmin should take action only to enable IPv6, not to remove the threads it represents today.
As a matter of interest, how can one tell if an ISP supports IPv6? This is slightly OT, but I often think I'd like to try using ipv6, but when I ask I'm given a purely theoretical reply, which I don't understand, usually involving SixXS. Are there simple instructions anywhere, just listing the commands to use, and not telling me how many people in China are using the internet.
Once upon a time, Timothy Murphy gayleard@alice.it said:
As a matter of interest, how can one tell if an ISP supports IPv6? This is slightly OT, but I often think I'd like to try using ipv6, but when I ask I'm given a purely theoretical reply, which I don't understand, usually involving SixXS. Are there simple instructions anywhere, just listing the commands to use, and not telling me how many people in China are using the internet.
Best way? Ask them. If the tech support doesn't know the answer, then they don't really "support" it (speaking as a long-time ISP system and network admin).
Other than that, it depends on how you connect. If you've got cable or DSL with a router running a DHCP client to get an address, see if it can also get an IPv6 address via DHCPv6 (hopefully with prefix delegation).
SixXS and HE are IPv6 tunnel brokers; while that will get you on the IPv6 Internet, it is not optimal (as you tunnel all your IPv6 traffic over IPv4 to a third party, so you can get sub-optimal routing).
I also would like to try using IPv6 periodically.
It's only recently, my local router had a firmware upgrade to support IPv6. The default setting for IPv6 within the router is still "Disabled". When I change this setting to "Auto Detect", the router gets an IPv6 address from the ISP. The router indicates the connection type, through the ISP is 6to4 Tunnel.
I need to reboot any device, which uses the router, to get IPv6 addresses. I have to check these devices to see if IPv6 is enabled on them.
The last time I did this, I found IPv6 had a little more latency than IPv4. After deciding the ISP and router were still "not there", I disabled IPv6. I haven't tried this recently, but this thread makes me want to try again. Hopefully the router has better firmware and the ISP IPv6 support has improved.
In answer to a question how does one tell if the ISP supports IPv6, I can only suggest turn IPv6 on and see if one gets a DHCP IPv6 address. If one gets an IPv6 address, one must still test things. One could possibly disable IPv4 to insure one is actually use IPv6.
On Wed, Jul 10, 2013 at 12:07 PM, Timothy Murphy gayleard@alice.it wrote:
Fernando Lozano wrote:
Given IPv6 current state, where many vulnerabilities are related to autoconfiguration for home and small networks, and given the fact many ISPs still doesn't support IPv6 at all, IMHO the default setting should be IPv6 disabled. Any end user or sysadmin should take action only to enable IPv6, not to remove the threads it represents today.
As a matter of interest, how can one tell if an ISP supports IPv6? This is slightly OT, but I often think I'd like to try using ipv6, but when I ask I'm given a purely theoretical reply, which I don't understand, usually involving SixXS. Are there simple instructions anywhere, just listing the commands to use, and not telling me how many people in China are using the internet.
-- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 School of Mathematics, Trinity College, Dublin 2, Ireland
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Hi,
The last time I did this, I found IPv6 had a little more latency than IPv4. After deciding the ISP and router were still "not there", I disabled IPv6. I haven't tried this recently, but this thread makes me want to try again. Hopefully the router has better firmware and the ISP IPv6 support has improved.
The problem is not just ISP support. Unless you have a pure IPv6 path end-to-end to the final destination (say google), your packets will travel through an IPv6-toIPv4 gateway, which add latency.
So, it won't bother your particular ISP supports IPv6 well, unless most internet sites you connect to also supports, and their own ISPs, load balancers, DNS mirrors, also supports IPv6 well.
Another question is that IPv4 has years of large-scale deployments, so well-optimized firmwares, OS stacks, firewalls, etc. IPv6 ones have less optimzation simply because they have been exposed to less real use and even less large scale use.
IPv6 per se (larger address size, larger headers, different semantics) requires more CPU power, memmory, buffers... so a product that works well with IPv6 may not work so well with IPv6. And the vendor has more pressure from customer for good performance on IPv4 than IPv6.
Bottom line: you won't use IPv6 because it's better. We may find out in the future it's actually much worse, but we will only know when it's as widely use as IPv4. We all know IPv6 is inevitable given the expansion of the Internet, but IPv6 is not need by most right now. Maybe we'll end up with a "different" IPv6, like current IPv4 with CIDR and NAT is very different than the original class-based IPv4.
For the time beign, I restrict IPv6 to test networks, to gain knowledge and evaulate product support, but keep it out of my production network. And keep a close eye to security issues and new RFCs still being drafted by the IETF about IPv6.
[]s, Fernando Lozano
On 07/10/2013 06:38 PM, Fernando Lozano wrote:
Bottom line: you won't use IPv6 because it's better. We may find out in the future it's actually much worse, but we will only know when it's as widely use as IPv4. We all know IPv6 is inevitable given the expansion of the Internet, but IPv6 is not need by most right now. Maybe we'll end up with a "different" IPv6, like current IPv4 with CIDR and NAT is very different than the original class-based IPv4.
IPv4 works as well as it does because we've had decades to work out the bugs and find the best way to make use of it. Eventually, we'll all be using IPv6, but unless there are people out there now, using it, (even if parts of the path are IPv4) we're never going to find any of the bugs or sub-optimal design decisions. Just like Fedora has rawhide, and beta-versions of new releases, we need people to be beta-testers for IPv6. That doesn't mean that everybody using Fedora needs to do that, just that it needs to be available if you want it, and that's true right now. When I go into Network Manager, and edit the connection I'm using right now, there's a tab for IPv6. Currently, I have it set to Ignore, but it's there so that anybody who wants to try it can set it up, just as easily as they do for IPv4. Possibly, some day, I'll find out if my ISP and router can handle it and if so, do some experimenting, but for the time being, I have too many other things on my mind.
Hi,
On 07/10/2013 06:38 PM, Fernando Lozano wrote:
Bottom line: you won't use IPv6 because it's better. We may find out in the future it's actually much worse, but we will only know when it's as widely use as IPv4. We all know IPv6 is inevitable given the expansion of the Internet, but IPv6 is not need by most right now. Maybe we'll end up with a "different" IPv6, like current IPv4 with CIDR and NAT is very different than the original class-based IPv4.
IPv4 works as well as it does because we've had decades to work out the bugs and find the best way to make use of it. Eventually, we'll all be using IPv6, but unless there are people out there now, using it, (even if parts of the path are IPv4) we're never going to find any of the bugs or sub-optimal design decisions.
And while we work out IPv6 and improve it, all users should be vulnerable to current IPv6 problems? Are they supposed to be guinea pigs for ipv6 development?
Fedora users in particular, including developers who are not concerned with network apps, and junior sysadmins who have Fedora as a learning tool, should be exposed to current IPv6 vulnerabilities?
The same way Fedora users get SELinux active by default, and iptables firewall rules, all in the name of security, they should *not* have IPv6 enabled by default. Those who wish to learn about and contribute to improve IPv6 could enable the feature themselves, not the other way, as it is the default for Fedora today.
See you yourself took care of disabling IPv6, but how many computer users will know they should? And how many Fedora user will know? Installation defaults should serve the majorty needs, not the IPv6 development agenda.
[]s, Fernando Lozano
On 07/10/2013 09:14 PM, fernando@lozano.eti.br wrote:
And while we work out IPv6 and improve it, all users should be vulnerable to current IPv6 problems? Are they supposed to be guinea pigs for ipv6 development?
No, of course not. I never said that everybody should have IPv6 active. What I did say is that it should be possible for an experienced user to activate it if they want to and that it's not only possible, it's easy if you're using Network Manager. And, to respond to something later in your post, I did not, in fact, disable IPv6; I simply declined to enable it, which is completely different. (And, I think, the default.)
Hi,
On 07/10/2013 09:14 PM, fernando@lozano.eti.br wrote:
And while we work out IPv6 and improve it, all users should be vulnerable to current IPv6 problems? Are they supposed to be guinea pigs for ipv6 development?
No, of course not. I never said that everybody should have IPv6 active. What I did say is that it should be possible for an experienced user to activate it if they want to and that it's not only possible, it's easy if you're using Network Manager. And, to respond to something later in your post, I did not, in fact, disable IPv6; I simply declined to enable it, which is completely different. (And, I think, the default.)
AFAIK all recent Windows releases and Linux distros have IPv6 enabled by default. Complete with auto-configuration, default MAC-based global addresses, route discovery and other "ease of use", but potentialy dangerous, features enabled.
I have not checked Fedora 19 yet. Didi it changed anything?
[]s, Fernando Lozano
Would test-ipv6.com or http://ipv6-test.com/validate.php give you the information you want? Or are you talking about a network you are not connected to...
billo
On Wed, 10 Jul 2013, Timothy Murphy wrote:
Fernando Lozano wrote:
Given IPv6 current state, where many vulnerabilities are related to autoconfiguration for home and small networks, and given the fact many ISPs still doesn't support IPv6 at all, IMHO the default setting should be IPv6 disabled. Any end user or sysadmin should take action only to enable IPv6, not to remove the threads it represents today.
As a matter of interest, how can one tell if an ISP supports IPv6? This is slightly OT, but I often think I'd like to try using ipv6, but when I ask I'm given a purely theoretical reply, which I don't understand, usually involving SixXS. Are there simple instructions anywhere, just listing the commands to use, and not telling me how many people in China are using the internet.
-- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 School of Mathematics, Trinity College, Dublin 2, Ireland
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Bill Oliver wrote:
Would test-ipv6.com or http://ipv6-test.com/validate.php give you the information you want? Or are you talking about a network you are not connected to...
Thanks very much, very useful. The second URL seemed to give an answer for any site I tried. It seems IPv6 sites are rather rare. I tried about a dozen sites in Ireland, including most universities, but only two came up positive: my own maths.tcd.ie and heanet.ie , which sort of runs the internet in Ireland. I tried about ten universities in the US, but the only ones that came up positive were Harvard and Yale.
It seems the first test is very simple, seeing if there is an AAAA DNS record. Then there is a second test which I did not understand. But no site that failed the AAAA test came good in the second.
So I guess IPv6 has a long way to go. I've always thought that whoever is meant to be "selling" IPv6 is not gifted in the area of common sense. I'd pass it over to Holland or Israel. (I think I'd pass NSA over to South Korea.)
On Wed, 2013-07-10 at 20:30 +0200, Timothy Murphy wrote:
It seems IPv6 sites are rather rare. I tried about a dozen sites in Ireland, including most universities, but only two came up positive: my own maths.tcd.ie and heanet.ie , which sort of runs the internet in Ireland.
Spare IPv4 addresses ran out a while ago. Since user ability to simply use IPv6 without knowing anything special is heavily limited by users have equipment that doesn't support it, OSs that don't fully implement it, or don't all implement it in the same way, take up will be slow. Requiring many users to have to do something, that they don't understand, to enable IPv6, or buy new equipment.
Many ISPs will, also, have to buy new equipment. For some of them, at great expense. They're not going to do that unless they have to. Some have been avoiding it just because the technicalities of it are a new nightmare that they don't want to have to deal with (new security issues, new network configuring, new customer support issues).
The interim solution has been to grab back already allocated, but currently un-used, IPv4 addresses. This solution will be short-lived, but I haven't seen an predictions for when it'll run out of available IPv4 addresses.
If manufacturers and software programmers don't pull their fingers out, we'll be faced with even more ISPs subjecting their clients to NAT.
It seems the first test is very simple, seeing if there is an AAAA DNS record. Then there is a second test which I did not understand. But no site that failed the AAAA test came good in the second.
If there is no IPv6 IP address for something, then there can be no IPv6 type of connection to it.
Hi Tim,
Many ISPs will, also, have to buy new equipment. For some of them, at great expense. They're not going to do that unless they have to. Some have been avoiding it just because the technicalities of it are a new nightmare that they don't want to have to deal with (new security issues, new network configuring, new customer support issues).
I don't know there, but here ISPs are not well known for investing in human resources. :-( I'd guess some big corporations will really adopt IPv6 before most ISPs. I just don't think it's time for SMBs to work (fight) with IPv6, they should wait for product to mature and best practives to be agreed to.
The interim solution has been to grab back already allocated, but currently un-used, IPv4 addresses. This solution will be short-lived, but I haven't seen an predictions for when it'll run out of available IPv4 addresses. If manufacturers and software programmers don't pull their fingers out, we'll be faced with even more ISPs subjecting their clients to NAT.
It seems the first test is very simple, seeing if there is an AAAA DNS record. Then there is a second test which I did not understand. But no site that failed the AAAA test came good in the second.
If there is no IPv6 IP address for something, then there can be no IPv6 type of connection to it.
Once upon a time, Fernando Lozano fernando@lozano.eti.br said:
I don't know there, but here ISPs are not well known for investing in human resources. :-( I'd guess some big corporations will really adopt IPv6 before most ISPs. I just don't think it's time for SMBs to work (fight) with IPv6, they should wait for product to mature and best practives to be agreed to.
The best practices have largely been agreed to (as much as any best practices ever are). IPv6 is as mature as it can get until a billion end-users get on it. Large ISPs around the world have rolled it out in production. Major OSes support it out-of-the-box.
If you don't even try to understand it, you are being left behind already.
Hi Chris,
The best practices have largely been agreed to (as much as any best practices ever are). IPv6 is as mature as it can get until a billion end-users get on it. Large ISPs around the world have rolled it out in production. Major OSes support it out-of-the-box. If you don't even try to understand it, you are being left behind already.
IPv6 has alot of "under the carpet" issues because vendors fear too much discussion about this will delay large-scale use even more. Every sane person agree the world needs to move to IPv6, but IMHO this is not being done in the most responsible manner.
I propose we let the billion dollars companies do the hard work, but at the same protect SMBs from IPv6. The Fedora Project could do their part by disabling IPv6 by default.
Please see my message providing links about IPv6 security threats, including recent slides (this year!) from IETF members. I do my homework before making statements on the net.
[]s, Fernando Lozano
Once upon a time, Fernando Lozano fernando@lozano.eti.br said:
IPv6 has alot of "under the carpet" issues because vendors fear too much discussion about this will delay large-scale use even more.
Again: citation needed. Without any actual issues sited, you are just spreading FUD.
I propose we let the billion dollars companies do the hard work, but at the same protect SMBs from IPv6. The Fedora Project could do their part by disabling IPv6 by default.
Again, you are years too late. Fedora would be greatly regressing (and falling far behind mainstream OSes) by disabling IPv6.
Please see my message providing links about IPv6 security threats, including recent slides (this year!) from IETF members. I do my homework before making statements on the net.
I took a look at a couple, but just saw more FUD and stopped.
Hi Chris,
[As I changed the subject, let me clear: IPv6 still compiled in the kernel. Just the network interfaces configs that should come with IPv6 disabled by default, if the user wants it should be easy to enable]
Once upon a time, Fernando Lozano fernando@lozano.eti.br said:
IPv6 has alot of "under the carpet" issues because vendors fear too much discussion about this will delay large-scale use even more.
Again: citation needed. Without any actual issues sited, you are just spreading FUD.
Works both ways. You can't claim I'm just spreading FUD withou evidence to corroborate your claim.
Anyway I've alread sent to the list evidence that the IPv6 security issues are real. As for "vendors fear too much discussion" it's really my personal interpretation of their silence, fell free to disagree. But please don't deny anymore there are IPv6 security issues, this is a hard fact.
I propose we let the billion dollars companies do the hard work, but at the same protect SMBs from IPv6. The Fedora Project could do their part by disabling IPv6 by default.
Again, you are years too late. Fedora would be greatly regressing (and falling far behind mainstream OSes) by disabling IPv6.
Fedora should take the lead and be more responsible to their users. It would be an improvement, not a regression.
Please see my message providing links about IPv6 security threats, including recent slides (this year!) from IETF members. I do my homework before making statements on the net.
I took a look at a couple, but just saw more FUD and stopped.
Fell free to ignore reallity when it doesn't agree with your personal opinion. But be warned reallity will hurt you anyway.
Or will you tell me that IETF people don't know what they are talking about? See for example:
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-07 http://tools.ietf.org/html/draft-gont-6man-flowlabel-security-03 http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-05
Papers from them, and even very recent RFCs on the security issues, can be foud if you take the time to follow my links and the links contained in them.
[]s, Fernando Lozano
Am 12.07.2013 17:49, schrieb Fernando Lozano:
[As I changed the subject, let me clear: IPv6 still compiled in the kernel. Just the network interfaces configs that should come with IPv6 disabled by default, if the user wants it should be easy to enable]
exactly *that* is my point
it is ridiculous that i bave a clearly static ipv4 config using network.service as well as "ipv6disable=1" as kernel param and on a F19 machine with 3.10.0-1.fc20.x86_64 eth0 comes up with "inet6 fe80::20c:29ff:fe30:82b9"
this is not a matter of ipv6 security / yes / no / don't know it is a matter of if ipv6 would make sense for the network and would enable and *properly* configure it but this is not the case because the gateway is for sure not ipv6 capable
i do not need to see any ip-address (ipv4 or ipv6) on a statically interface which was not explicitly configured
[root@rawhide ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:0c:29:30:82:b9 ONBOOT=yes BOOTPROTO=static TYPE=Ethernet MODE=Managed IPADDR=192.168.196.18 NM_CONTROLLED=no IPV6INIT=no NETMASK=255.255.255.0 GATEWAY=192.168.196.2 USERCTL=no MTU=1500
[root@rawhide ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 inet6 fe80::20c:29ff:fe30:82b9 prefixlen 64 scopeid 0x20<link> ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet) RX packets 1271 bytes 104193 (101.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1049 bytes 122041 (119.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Hi,
[As I changed the subject, let me clear: IPv6 still compiled in the kernel. Just the network interfaces configs that should come with IPv6 disabled by default, if the user wants it should be easy to enable] exactly *that* is my point
it is ridiculous that i bave a clearly static ipv4 config using network.service as well as "ipv6disable=1" as kernel param and on a F19 machine with 3.10.0-1.fc20.x86_64 eth0 comes up with "inet6 fe80::20c:29ff:fe30:82b9"
this is not a matter of ipv6 security / yes / no / don't know it is a matter of if ipv6 would make sense for the network and would enable and *properly* configure it but this is not the case because the gateway is for sure not ipv6 capable
i do not need to see any ip-address (ipv4 or ipv6) on a statically interface which was not explicitly configured
Having a smarter ifconfig / ip tool or ethernet device driver would be a way to implement my proposal.
But, by the IPv6 RTFs, just having IPv6 enabled means there is an IPv6 address for that interface. IPv6 provides local auto-configuration for network intefaces, without DHCP or any other infrastrucure being present.
That's one thing that creates security risks: you don't know you could be reached by that address.
So, ifconfig or ip or whatever would have to disable IPv6 for any interface that does not having an explicit IPv6 address. I'd think it would be easier to have the default eth*-cfg files and Network Manager disable IPv6 unless the user tells them to enable.
[]s, Fernando Lozano
Am 12.07.2013 18:44, schrieb Fernando Lozano:
[As I changed the subject, let me clear: IPv6 still compiled in the kernel. Just the network interfaces configs that should come with IPv6 disabled by default, if the user wants it should be easy to enable] exactly *that* is my point
it is ridiculous that i bave a clearly static ipv4 config using network.service as well as "ipv6disable=1" as kernel param and on a F19 machine with 3.10.0-1.fc20.x86_64 eth0 comes up with "inet6 fe80::20c:29ff:fe30:82b9"
this is not a matter of ipv6 security / yes / no / don't know it is a matter of if ipv6 would make sense for the network and would enable and *properly* configure it but this is not the case because the gateway is for sure not ipv6 capable
i do not need to see any ip-address (ipv4 or ipv6) on a statically interface which was not explicitly configured
Having a smarter ifconfig / ip tool or ethernet device driver would be a way to implement my proposal.
But, by the IPv6 RTFs, just having IPv6 enabled means there is an IPv6 address for that interface. IPv6 provides local auto-configuration for network intefaces, without DHCP or any other infrastrucure being present.
That's one thing that creates security risks: you don't know you could be reached by that address.
So, ifconfig or ip or whatever would have to disable IPv6 for any interface that does not having an explicit IPv6 address. I'd think it would be easier to have the default eth*-cfg files and Network Manager disable IPv6 unless the user tells them to enable.
hence it would be enough if "ifup" would respect the configuration i can not see "just having IPv6 enabled means there is an IPv6 address" below - where is there ipv6 enabled? there is even a "IPV6INIT=no"
jesus this is a *ipv6 disabled* interface and it has a link-local address and NM does not run here at all because on complex network configuration with different interfaces "network.service" is the better way (MHO and IMHO is enough on machines i am responsible for) http://www.cyberciti.biz/faq/rhel-redhat-fedora-centos-ipv6-network-configur...
[root@rawhide ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:0c:29:30:82:b9 ONBOOT=yes BOOTPROTO=static TYPE=Ethernet MODE=Managed IPADDR=192.168.196.18 NM_CONTROLLED=no IPV6INIT=no NETMASK=255.255.255.0 GATEWAY=192.168.196.2 USERCTL=no MTU=1500
[root@rawhide ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 inet6 fe80::20c:29ff:fe30:82b9 prefixlen 64 scopeid 0x20<link> ether 00:0c:29:30:82:b9 txqueuelen 1000 (Ethernet) RX packets 2046 bytes 170804 (166.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1608 bytes 176828 (172.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Hi,
hence it would be enough if "ifup" would respect the configuration i can not see "just having IPv6 enabled means there is an IPv6 address" below - where is there ipv6 enabled? there is even a "IPV6INIT=no"
I have overlooked that. I'm not a Fedora developer, have to check if IPV6INIT means what me and you think it means, but I guess this is a bug.
Have you checked https://bugzilla.redhat.com/show_bug.cgi?id=982740 ?
[]s, Fernando Lozano
Am 12.07.2013 19:41, schrieb Fernando Lozano:
hence it would be enough if "ifup" would respect the configuration i can not see "just having IPv6 enabled means there is an IPv6 address" below - where is there ipv6 enabled? there is even a "IPV6INIT=no"
I have overlooked that. I'm not a Fedora developer, have to check if IPV6INIT means what me and you think it means, but I guess this is a bug.
Have you checked https://bugzilla.redhat.com/show_bug.cgi?id=982740?
yes i have "NETWORKING_IPV6=no" since virtually forever in "/etc/sysconfig/network" as well as "IPV6INIT=false" in the interface configurations
this was most time ignored
after that i found out a modprobe-config like statet "install ipv6 /bin/true" does the trick but this is no longer true since a long time
later there where some settings in /etc/sysctl.conf which worked a longe time until somewhere around F18 where "ipv6.disable=1" as kernel boot-param was sugessted after mailing to devel/systemd list and bugreports
since this also does not work in recent environments my simple question by starting the thread was "which magic is now the best" and i was *not* interested in evangelists explaining how superiour ipv6 is as answer because it is *off-topic* for networks behind gateways which are not ipv6 capable and opens only *security problems* in LAN environments
you need not a security hole in the protocl - the simple presence of it is one in environments where it is not needed is a security problem and violates best practices "disable anything which is not actively used" - period
Hi,
Have you checked https://bugzilla.redhat.com/show_bug.cgi?id=982740?
yes i have "NETWORKING_IPV6=no" since virtually forever in "/etc/sysconfig/network" as well as "IPV6INIT=false" in the interface configurations
this was most time ignored
I wasn't aware this bug was so serious. Please add your findings to the bug, so Fedora developers can test all scenarios when releasing a fix.
since this also does not work in recent environments my simple question by starting the thread was "which magic is now the best" and i was *not* interested in evangelists explaining how superiour ipv6 is as answer because it is *off-topic* for networks behind gateways which are not ipv6 capable and opens only *security problems* in LAN environments
you need not a security hole in the protocl - the simple presence of it is one in environments where it is not needed is a security problem and violates best practices "disable anything which is not actively used" - period
That's the reason I proposed IPv6 disabled by default.
Sorry for mixing it up with your question.
[]s, Fernando Lozano
Fernando Lozano <fernando <at> lozano.eti.br> writes:
Hi,
[As I changed the subject, let me clear: IPv6 still compiled in the
kernel. Just the network interfaces configs <SNIP>
Perhaps Fedora is the wrong distribution for you.
The whole idea behind Fedora is for it to be an "engineering proving ground" where new technologies (like IPv6) are rolled out for real world use. In the case of IPv6, this includes hopefully providing the tools required for users to be able to securely run a Fedora system with IPv6 enabled. If there is a problem with the tools provided then the answer is to fix the tools and/or provide additional tools; not pull back from a technology that IS coming.
Cheers, Dave
Am 12.07.2013 20:24, schrieb David G.Miller:
Fernando Lozano <fernando <at> lozano.eti.br> writes:
[As I changed the subject, let me clear: IPv6 still compiled in the
kernel. Just the network interfaces configs
<SNIP>
Perhaps Fedora is the wrong distribution for you.
The whole idea behind Fedora is for it to be an "engineering proving ground" where new technologies (like IPv6) are rolled out for real world use. In the case of IPv6, this includes hopefully providing the tools required for users to be able to securely run a Fedora system with IPv6 enabled. If there is a problem with the tools provided then the answer is to fix the tools and/or provide additional tools; not pull back from a technology that IS coming
why this polemic answer?
it is legit and recommended to disable ipv6 link-local on machines inside a network with a ipv4-only gateway because it is not needed, makes no sense and you should *never* enable network capabilities which are not used
the main problem is not be able to *disable* it if you know what you are doing and know why therese is no need for ipv6 in your environment https://bugzilla.redhat.com/show_bug.cgi?id=982740
Am 12.07.2013 20:24, schrieb David G.Miller:
Fernando Lozano <fernando <at> lozano.eti.br> writes:
[As I changed the subject, let me clear: IPv6 still compiled in the
kernel. Just the network interfaces configs
<SNIP>
Perhaps Fedora is the wrong distribution for you.
The whole idea behind Fedora is for it to be an "engineering proving ground" where new technologies (like IPv6) are rolled out for real world use. In the case of IPv6, this includes hopefully providing the tools required for users to be able to securely run a Fedora system with IPv6 enabled. If there is a problem with the tools provided then the answer is to fix the tools and/or provide additional tools; not pull back from a technology that IS coming
why this polemic answer?
it is legit and recommended to disable ipv6 link-local on machines inside a network with a ipv4-only gateway because it is not needed, makes no sense and you should *never* enable network capabilities which are not used
the main problem is not be able to *disable* it if you know what you are doing and know why therese is no need for ipv6 in your environment https://bugzilla.redhat.com/show_bug.cgi?id=982740
I don't consider my response to be "polemic." Just pointing out that Fedora tends to be a "bleeding edge", development distribution. As an example, you might review the commentary regarding the new installer that appeared in FC-18. The same can be said for any number of new features such as systemctl instead of System V init scripts and firewalld as well as many others.
That being said, you and Fernando might wish to explore how to submit a feature request to make enabling/disabling IPv6 easier and more intuitive. Such a feature would be more in keeping with Fedora's goal of being a technology incubator for what eventually becomes RHEL. Simply turning off a new technology that some people find inconvenient but that will move from optional to required in the foreseeable future is contrary to what Fedora is all about.
Cheers, Dave
Am 12.07.2013 22:17, schrieb dave@davenjudy.org:
Am 12.07.2013 20:24, schrieb David G.Miller:
Fernando Lozano <fernando <at> lozano.eti.br> writes:
[As I changed the subject, let me clear: IPv6 still compiled in the
kernel. Just the network interfaces configs
<SNIP>
Perhaps Fedora is the wrong distribution for you.
The whole idea behind Fedora is for it to be an "engineering proving ground" where new technologies (like IPv6) are rolled out for real world use. In the case of IPv6, this includes hopefully providing the tools required for users to be able to securely run a Fedora system with IPv6 enabled. If there is a problem with the tools provided then the answer is to fix the tools and/or provide additional tools; not pull back from a technology that IS coming
why this polemic answer?
it is legit and recommended to disable ipv6 link-local on machines inside a network with a ipv4-only gateway because it is not needed, makes no sense and you should *never* enable network capabilities which are not used
the main problem is not be able to *disable* it if you know what you are doing and know why therese is no need for ipv6 in your environment https://bugzilla.redhat.com/show_bug.cgi?id=982740
I don't consider my response to be "polemic." Just pointing out that Fedora tends to be a "bleeding edge", development distribution.
that doe snot mean ipv6 has to be mandatory
As an example, you might review the commentary regarding the new installer that appeared in FC-18. The same can be said for any number of new features such as systemctl instead of System V init scripts and firewalld as well as many others.
completly different topic
the installer is not connected to the network and ipv6 was laways enabled by default, *but* until now i found no way to diable it on F19 with a F20 kernel
That being said, you and Fernando might wish to explore how to submit a feature request to make enabling/disabling IPv6 easier and more intuitive. Such a feature would be more in keeping with Fedora's goal of being a technology incubator for what eventually becomes RHEL.
no - that is not a feature see the bugreport above
there has only be a clear way to disable it which does not change randomly - maybe you think i support the proposal disable it by default which is *not* the case, i only *need* to disable it for security reasons in *production* environments and as admin it has to be *always* my job to deice if a device needs whatever network protocol supported
Simply turning off a new technology that some people find inconvenient but that will move from optional to required in the foreseeable future is contrary to what Fedora is all about.
i did not propose this with *any* word!
Hi,
Perhaps Fedora is the wrong distribution for you.
The whole idea behind Fedora is for it to be an "engineering proving ground" where new technologies (like IPv6) are rolled out for real world use.
Not all Fedora users work in the networking fields. Many are developers who doesn't care about networking. Even most web, client-server and mobile developers are not close to being security experts and would configure a very insecure system if left by thenselves. This does not exclude them from being superb C, Java, PHP, Python, etc developers.
I don't think it's a good policy to exclude some users because of others. And I don't thing people are understanding how real and serious are current IPv6 vulnerabilities.
Biut I ask: would it be so hard for networking people to click once on anaconda or Network Manager to enable IPv6 if? I think it's harder for non-networking people to understand they should disable IPv6 else know how to configure IPv6 in a secure way.
the main problem is not be able to *disable* it if you know what you are doing and know why therese is no need for ipv6 in your environment https://bugzilla.redhat.com/show_bug.cgi?id=982740
IMHO those are two distinct issue, although related:
1. Users should be able to disable IPv6. Today they can't and this is a bug that hopefully will be solved soon. I think no one ever intended IPv6 to be mandatory. ;-)
2. The secure installation default should be IPv6 disabled. That's my proposal.
[]s, Fernando Lozano
On 07/12/2013 02:17 PM, Fernando Lozano wrote:
- Users should be able to disable IPv6. Today they can't and this is a
bug that hopefully will be solved soon. I think no one ever intended IPv6 to be mandatory. ;-)
Actually, they can, but they have to take the time to configure the connection instead of just accepting the defaults. When you use Network Manager, if you edit the connection there's a tab for IPv6 and you can set it to Ignore, as I have. Easy, simple, clear, but as I said, you have to look for it. Should Ignore be the default? I don't know, honestly.
Hi joe,
On 07/12/2013 02:17 PM, Fernando Lozano wrote:
- Users should be able to disable IPv6. Today they can't and this is a
bug that hopefully will be solved soon. I think no one ever intended IPv6 to be mandatory. ;-)
Actually, they can, but they have to take the time to configure the connection instead of just accepting the defaults. When you use Network Manager, if you edit the connection there's a tab for IPv6 and you can set it to Ignore, as I have. Easy, simple, clear, but as I said, you have to look for it. Should Ignore be the default? I don't know, honestly.
If you see the bug cited earlier current Fedora (19) has a bug where settings to disable IPv6 are ignored. But IMHO that's a different question, a simple bug that can (will) be fixed.
IMHO "have to look" should not be required by most users. IPv6 today serves networing people. Fedora is not only for networking people, and I from my experience most Fedora users are not networking people. Do we have data about Fedora user demographics?
[]s, Fernando Lozano
On 07/12/2013 02:38 PM, Fernando Lozano wrote:
IMHO "have to look" should not be required by most users. IPv6 today serves networing people. Fedora is not only for networking people, and I from my experience most Fedora users are not networking people. Do we have data about Fedora user demographics?
I agree. That's why I made a point out of the fact that you have to take the time and effort to find the right place. Not that it's hard, but it either should be disabled by default, or you should be asked when the connection's set up, probably with disabled as the default, so that inexperienced users won't end up with something the don't need, especially as waiting for IPv6 to come up or time out when your ISP doesn't provide it just slows your boot down.
Am 12.07.2013 23:33, schrieb Joe Zeff:
On 07/12/2013 02:17 PM, Fernando Lozano wrote:
- Users should be able to disable IPv6. Today they can't and this is a
bug that hopefully will be solved soon. I think no one ever intended IPv6 to be mandatory. ;-)
Actually, they can, but they have to take the time to configure the connection instead of just accepting the defaults. When you use Network Manager, if you edit the connection there's a tab for IPv6 and you can set it to Ignore, as I have. Easy, simple, clear, but as I said, you have to look for it. Should Ignore be the default? I don't know, honestly
so please read this and if possible please tell me the magic where NM writes whatever in a unknown config file to get rid of the ipv6-link-local address
On 12.07.2013 18:44, Fernando Lozano wrote: …
So, ifconfig or ip or whatever would have to disable IPv6 for any interface that does not having an explicit IPv6 address. I'd think it would be easier to have the default eth*-cfg files and Network Manager disable IPv6 unless the user tells them to enable.
Looks like you're reading a lot of documents, so it wouldn't be bad to also read these[1] quite simple guidelines. Take into consideration that some of distro binaries are built with an IPv6 on mind.
poma
[1] https://www.kernel.org/doc/Documentation/networking/ipv6.txt
Hi,
On 12.07.2013 18:44, Fernando Lozano wrote: …
So, ifconfig or ip or whatever would have to disable IPv6 for any interface that does not having an explicit IPv6 address. I'd think it would be easier to have the default eth*-cfg files and Network Manager disable IPv6 unless the user tells them to enable.
Looks like you're reading a lot of documents, so it wouldn't be bad to also read these[1] quite simple guidelines. Take into consideration that some of distro binaries are built with an IPv6 on mind.
[1] https://www.kernel.org/doc/Documentation/networking/ipv6.txt
Your "guidelines" are none at all. Those are docs for a kernel module, their options. Important docs, but just "command reference", not guidelines.
Unfortunately those module options are currently not being honored (bug already opened). Changing those defaults (specifically, disabled=1 being the new default) would be a way to implement what I propose. But I guess it would not be easy for NetworkManager to change this and reload ipv6 module. Maybe I'm wrong abou that.
About binaries requiring ipv6, that's like expecting a package that needs a database to create the database as part of its install. Most ones I tried won't -- they will depend on the database client package, but will need the user/sysadmin to setup the database before starting the software included on the package. IPv6 disabled would be just like that: whoever installs something that requires IPv6 enabled would simply have to enable it.
Defaults should suit most users. Not a minority that requires IPv6 enabled and how how to manage it.
[]s, Fernando Lozano
On 12.07.2013 23:53, Fernando Lozano wrote:
Hi,
On 12.07.2013 18:44, Fernando Lozano wrote: …
So, ifconfig or ip or whatever would have to disable IPv6 for any interface that does not having an explicit IPv6 address. I'd think it would be easier to have the default eth*-cfg files and Network Manager disable IPv6 unless the user tells them to enable.
Looks like you're reading a lot of documents, so it wouldn't be bad to also read these[1] quite simple guidelines. Take into consideration that some of distro binaries are built with an IPv6 on mind.
[1] https://www.kernel.org/doc/Documentation/networking/ipv6.txt
Your "guidelines" are none at all. Those are docs for a kernel module, their options. Important docs, but just "command reference", not guidelines.
Certainly, it's your understanding of the matter. :)
Unfortunately those module options are currently not being honored (bug already opened). Changing those defaults (specifically, disabled=1 being the new default) would be a way to implement what I propose. But I guess it would not be easy for NetworkManager to change this and reload ipv6 module. Maybe I'm wrong abou that.
What is written in the 'ipv6.txt' certainly works. Posing as a network expert, it seems you don't understand such a simple instruction. :)
About binaries requiring ipv6, that's like expecting a package that needs a database to create the database as part of its install. Most ones I tried won't -- they will depend on the database client package, but will need the user/sysadmin to setup the database before starting the software included on the package. IPv6 disabled would be just like that: whoever installs something that requires IPv6 enabled would simply have to enable it.
The whole thing about the choice of version isn't simple at all.
Defaults should suit most users. Not a minority that requires IPv6 enabled and how how to manage it.
Are you a representative of the majority of users? :) BTW, I recommend this issue to present to 'fedora-devel', otherwise people will take all of this as a good joke. :)
poma
Am 13.07.2013 01:18, schrieb poma:
Unfortunately those module options are currently not being honored (bug already opened). Changing those defaults (specifically, disabled=1 being the new default) would be a way to implement what I propose. But I guess it would not be easy for NetworkManager to change this and reload ipv6 module. Maybe I'm wrong abou that.
What is written in the 'ipv6.txt' certainly works. Posing as a network expert, it seems you don't understand such a simple instruction. :)
it *does not* work and if you have read the thread you would have followed the bugreport!
Hi,
Unfortunately those module options are currently not being honored (bug already opened).
What is written in the 'ipv6.txt' certainly works.
Have you tried?
Because there are other people on the list claiming it isn't working.
About binaries requiring ipv6, that's like expecting a package that needs a database to create the database as part of its install. Most ones I tried won't -- they will depend on the database client package, but will need the user/sysadmin to setup the database before starting the software included on the package. IPv6 disabled would be just like that: whoever installs something that requires IPv6 enabled would simply have to enable it.
The whole thing about the choice of version isn't simple at all.
Choosing between IPv4 and IPv6 is not like choosing PostgreSQL 8 or 9. It's like choosing MySQL or PostgreSQL. Different software, that require different configuration before any app can use them. I was making the analogy that a PostgreSQL app may install ok from RPM but require the sysadmin to configure the database (creating users, schema, importing initial data). So requiring a sysadmin to setup IPv6 (like enabling it for a network card) would be similar. Disabling IPv6 by default would not make it harder IMHO to install binaries that require IPv6.
Defaults should suit most users. Not a minority that requires IPv6 enabled and how how to manage it.
Are you a representative of the majority of users? :)
Of course not. :-) I can only talk about the ones I know and see if my sample is similar to others on the list.
BTW, I recommend this issue to present to 'fedora-devel', otherwise people will take all of this as a good joke. :)
If people on the users list don't agree with me, there's no point submiting to developers.
[]s, Fernando Lozano
On Sat, Jul 13, 2013 at 1:25 PM, Fernando Lozano fernando@lozano.eti.br wrote:
If people on the users list don't agree with me, there's no point submiting to developers.
Well I for one certainly don't agree with you. If you disable it everywhere it's too much of a pain to turn it all back on when you need it.
If I want IPv6, I don't want to have to a) enable it in the firewall b) enable it in the kernel c) enable it in every application.
As it stands it is enabled for b) and sometimes in c) and blocked in a) for the most part. The simplest way is for users to configure the firewall to let IPv6 in and have the rest already setup.
So I think the default should be to have it enabled everywhere where appropriate except the firewall. IPv6 is designed to be autoconfiguring. Unless you actually have a global IPv6 address, you can only use it locally anyway. F19 now has the firewall with zones home, work, public etc so it can do the right thing from a security standpoint.
If you are worried about security you should be raising bugs against the firewall, not disabling IPv6 completely.
dave
Am 13.07.2013 13:07, schrieb David Beveridge:
On Sat, Jul 13, 2013 at 1:25 PM, Fernando Lozano fernando@lozano.eti.br wrote:
If people on the users list don't agree with me, there's no point submiting to developers.
Well I for one certainly don't agree with you. If you disable it everywhere it's too much of a pain to turn it all back on when you need it.
i disagree also that it should be default disabled *but* it should be disabled if you are on a network with only a DHCP4 server and no DHCP6 or if you have a static configuration without ipv6
currently you get a link-local address
IPv6 is designed to be autoconfiguring
and *that* is a problem inside a ipv4 only LAN
Unless you actually have a global IPv6 address, you can only use it locally anyway.
"locally" is enough
a) nowadyas many attacks are coming from inside the LAN
b) you may be vulnerable if a foreign device comes up with ipv6, your firewalls only configured for ipv4 and your server got a link-local ipv6
c) services and applications may see the link-local address and think "hey i can fully operate with ipv6" which is not true
F19 now has the firewall with zones home, work, public etc so it can do the right thing from a security standpoint.
there are environments with "iptables-services" for very good reasons
If you are worried about security you should be raising bugs against the firewall, not disabling IPv6 completely
no - if you are a sane admin you do not want *anything* enabled which does not match the big picture of the environment
keep in mind that there are environemnts far outside the single workstation and security is *always* the big picture of the complete environment and the weakest piece defines your overall security
On Sat, Jul 13, 2013 at 6:15 AM, Reindl Harald h.reindl@thelounge.netwrote:
Am 13.07.2013 13:07, schrieb David Beveridge:
On Sat, Jul 13, 2013 at 1:25 PM, Fernando Lozano fernando@lozano.eti.br
wrote:
If people on the users list don't agree with me, there's no point submiting to developers.
Well I for one certainly don't agree with you. If you disable it everywhere it's too much of a pain to turn it all back on when you need it.
i disagree also that it should be default disabled *but* it should be disabled if you are on a network with only a DHCP4 server and no DHCP6 or if you have a static configuration without ipv6
currently you get a link-local address
IPv6 is designed to be autoconfiguring
and *that* is a problem inside a ipv4 only LAN
Unless you actually have a global IPv6 address, you can only use it locally anyway.
"locally" is enough
a) nowadyas many attacks are coming from inside the LAN
b) you may be vulnerable if a foreign device comes up with ipv6, your firewalls only configured for ipv4 and your server got a link-local ipv6
c) services and applications may see the link-local address and think "hey i can fully operate with ipv6" which is not true
F19 now has the firewall with zones home, work, public etc so it can do the right thing from a security standpoint.
there are environments with "iptables-services" for very good reasons
If you are worried about security you should be raising bugs against the firewall, not disabling IPv6 completely
no - if you are a sane admin you do not want *anything* enabled which does not match the big picture of the environment
keep in mind that there are environemnts far outside the single workstation and security is *always* the big picture of the complete environment and the weakest piece defines your overall security
If an administrator or a normal user can't disable IPv6, this is a bug and needs to be fixed.
I feel the question, should IPv6 be disabled by default, is aimed for casual users, not administrators. Administrators should know what they are doing.
Please correct me if I am wrong, but I believe an administrator would want to do a custom install to control exactly what services are installed and would be willing to control the initial state of IPv6, also during an install.
Would administrators be okay if they had an option, during Fedora install/upgrade, where they can set the state of IPv6?
The more important question, would having an option, during Fedora install/upgrade, for setting the state of IPv6 help or confuse normal users? What should the suggested default be?
Again, administrators know what they are doing. I'm more concerned with people who don't know what they are doing.
Am 14.07.2013 01:15, schrieb Richard Sewill:
keep in mind that there are environemnts far outside the single workstation and security is *always* the big picture of the complete environment and the weakest piece defines your overall security
If an administrator or a normal user can't disable IPv6, this is a bug and needs to be fixed.
and that is why i started the thread
I feel the question, should IPv6 be disabled by default, is aimed for casual users, not administrators. Administrators should know what they are doing
and that is why i *did not* start the thread with this topic
the problem is that *three* sorts of evangelists hijacked the original thread and changed multiple times the topic
On Sun, 14 Jul 2013, Reindl Harald wrote:
the problem is that *three* sorts of evangelists hijacked the original thread and changed multiple times the topic
If they changed the subject line accordingly, what is the problem? Do you have a mail-reader that does not show subject lines?
I've had replies to my signature lines. I didn't go nuclear over them.
Am 15.07.2013 23:19, schrieb Michael Hennebry:
On Sun, 14 Jul 2013, Reindl Harald wrote:
the problem is that *three* sorts of evangelists hijacked the original thread and changed multiple times the topic
If they changed the subject line accordingly, what is the problem?
*tree view* i said *tree view*
is it really so difficult to understand that it is better to make "Proposal: Fedora should install with IPv6 disabled by default" a own thread as well as explain the world that ipv6 is the best you can have even if you are on a ipv4 only network with no ipv6 gateway in the near future?
Do you have a mail-reader that does not show subject lines?
so do you not have a delete button if you do not want to read my mails if they are sometimes to rude for whoever?
that's exactly the same
* i get demanded to answer always in a specific way * so i demand to answer my threads in a specific way
period
On Mon, 15 Jul 2013, Reindl Harald wrote:
Am 15.07.2013 23:19, schrieb Michael Hennebry:
On Sun, 14 Jul 2013, Reindl Harald wrote:
the problem is that *three* sorts of evangelists hijacked the original thread and changed multiple times the topic
If they changed the subject line accordingly, what is the problem?
*tree view* i said *tree view*
Maybe you should upgrade to a tree viewer that shows subject lines.
Am 16.07.2013 09:12, schrieb Michael Hennebry:
On Mon, 15 Jul 2013, Reindl Harald wrote:
Am 15.07.2013 23:19, schrieb Michael Hennebry:
On Sun, 14 Jul 2013, Reindl Harald wrote:
the problem is that *three* sorts of evangelists hijacked the original thread and changed multiple times the topic
If they changed the subject line accordingly, what is the problem?
*tree view* i said *tree view*
Maybe you should upgrade to a tree viewer that shows subject lines
WTF
i find it uncomfortable having different topics in the same thread - period - maybe *you* have a different point of view and would change yours too afer a bundlde of medical operations on your eyes - period
i disagree also that it should be default disabled *but* it should be disabled if you are on a network with only a DHCP4 server and no DHCP6 or if you have a static configuration without ipv6
currently you get a link-local address
This is by design. And with ipv6 incoming (big in Asia and basis ISPs are beginning to enabled it now for home users in the US such as Comcast. Windows will work out of the box. MacOSX will work out of the box. Fedora (or Ubuntu etc) also need to work out of the box.
IPv6 is designed to be autoconfiguring
and *that* is a problem inside a ipv4 only LAN
Not if you are sane with your policies as an admin anyway.
"locally" is enough
a) nowadyas many attacks are coming from inside the LAN
True internal attacks are a problem. But layer 2 (remember fe80:: is local link only and cannot be routed) are rarer... Psychical security to prevent layer 2 access in the first place is important. In addition do you systems get sufficiently tight on their iptables configurations that you are manually listing IP addresses that are allowed to ssh in? If you are being that controlling it would be trivial to configure ip6tables to reject or drop all packets via the similar methods you are controlling iptables. If you are not being that controlling then this point is moot since the default ip6tables only allows ssh and related/established connections just like iptables.
b) you may be vulnerable if a foreign device comes up with ipv6, your firewalls only configured for ipv4 and your server got a link-local ipv6
Why do you have a foreign service appear on your local link? The same physical and layer 2 thoughts apply. This is essentially point a again and the detail in there stands.
c) services and applications may see the link-local address and think "hey i can fully operate with ipv6" which is not true
Then file a bug for that application. The RFCs are very clear with the prefixes well established. An fe80:: address is link local only and an application that sees this address and no 2000::/3 address should not think they have a global address and attempt to use it... The situation is admittedly blurred when ULA addressing comes into play but at that point you have made ipv6 configuration and policy choices which should take things like this into account when doing so.
no - if you are a sane admin you do not want *anything* enabled which does not match the big picture of the environment
A sane admin is aware of emerging technologies and the requirements surrounding them in order to adapt as new things come along.
keep in mind that there are environemnts far outside the single workstation and security is *always* the big picture of the complete environment and the weakest piece defines your overall security
And I will repeat that we are talking link local addresses here... Ip6tables is a trivial easy way to block ipv6 communication in a same manner you presumably already manage iptables since the scope of this bit is the context of large environments whereupon you are talking probably smaller broadcast domains to begin with (ie a vlan per floor of building or something similar) and that the same layer 2 security for your network applies...
Hi,
i disagree also that it should be default disabled *but* it should be disabled if you are on a network with only a DHCP4 server and no DHCP6 or if you have a static configuration without ipv6
currently you get a link-local address
This is by design. And with ipv6 incoming (big in Asia and basis ISPs are beginning to enabled it now for home users in the US such as Comcast. Windows will work out of the box. MacOSX will work out of the box. Fedora (or Ubuntu etc) also need to work out of the box.
I don't think anything is the "right thing" just because Windows and MacOS will do. In this specific case, my optinion is that they shouln't, the same way Fedora shouldnt'.
If sometone needs IPv6 working out-of-the-box, it could be a check box on anaconda.
IPv6 is designed to be autoconfiguring
and *that* is a problem inside a ipv4 only LAN
Not if you are sane with your policies as an admin anyway.
Cannot hope that with most home LANS and SMBs.
[]s, Fernando Lozano
On Fri, 2013-07-12 at 08:54 -0500, Chris Adams wrote:
The best practices have largely been agreed to (as much as any best practices ever are). IPv6 is as mature as it can get until a billion end-users get on it. Large ISPs around the world have rolled it out in production. Major OSes support it out-of-the-box.
If you don't even try to understand it, you are being left behind already.
Not a great deal of use for the standalone user to have to deal with how it works if they can't use it without changing ISPs, or have no alternative ISP that supports it to change to.
Hi Tim,
Many ISPs will, also, have to buy new equipment. For some of them, at great expense. They're not going to do that unless they have to. Some have been avoiding it just because the technicalities of it are a new nightmare that they don't want to have to deal with (new security issues, new network configuring, new customer support issues).
Here ISPs are not well known for spending in training. :-( I'd guess big corporations will adopt IPv6 before most ISPs. I don't think it's the time for SMBs to try (fight with) IPv6, they should wait until products mature and best practices to emerge. In the mean time, vendors should be honest and disable IPv6 (not remove, just disable)
The interim solution has been to grab back already allocated, but currently un-used, IPv4 addresses. This solution will be short-lived, but I haven't seen an predictions for when it'll run out of available IPv4 addresses. If manufacturers and software programmers don't pull their fingers out, we'll be faced with even more ISPs subjecting their clients to NAT.
Would this be so bad? Most people at work have been working using NAT for years. NAT increases security. Most internet users don't need to run servers.
[]s, Fernando Lozano
Once upon a time, Fernando Lozano fernando@lozano.eti.br said:
Would this be so bad? Most people at work have been working using NAT for years. NAT increases security. Most internet users don't need to run servers.
NAT does NOT increase security. NAT is a combination of a stateful firewall with a packet mangler; the security comes from the firewall, not the mangler. Leave out the packet mangling; use a firewall and "real" IPs.
Lots of Internet users run servers and don't even know it; any peer to peer system is a server on one end. Look at all the hoops software has to jump through to try to work through NAT (and especially multiple layers of NAT), sometimes failing and frustrating users.
As IPv4 runs out, some ISPs are turning to "Carrier Grade NAT", which adds layers of NAT that break things like P2P applications and IPSec.
In any case, IPv6 should be enabled by default because users may connect to IPv6 networks and need it to "just work", just like IPv4. They aren't power users that know how to tweak hidden options, they just want to use the network.
Hi,
Would this be so bad? Most people at work have been working using NAT for years. NAT increases security. Most internet users don't need to run servers.
NAT does NOT increase security. NAT is a combination of a stateful firewall with a packet mangler; the security comes from the firewall, not the mangler. Leave out the packet mangling; use a firewall and "real" IPs.
If NAT prevents anyone from the internet to try to connect to my computer, this is increased security. After all, don't we configure firewalls exactly to prevent unwanted connections?
Of course NAT alone does not brings security. But as I understand TCP/IP networks, NAT does help security.
Not having NAT means having everyone, every device and computer with a real, public internet address. This means more potential targets for hackers.
Lots of Internet users run servers and don't even know it; any peer to peer system is a server on one end. Look at all the hoops software has to jump through to try to work through NAT (and especially multiple layers of NAT), sometimes failing and frustrating users.
NAT is a fact today, has been for years, and people have been using Bittorrent and Skype regardless.
For home users and SMBs, NAT is something that was taken care of. IPv6 is a whole new bunch of risks. I am not against IPv6 per se. I am against wide use of IPv6 right now. Let it mature.
As IPv4 runs out, some ISPs are turning to "Carrier Grade NAT", which adds layers of NAT that break things like P2P applications and IPSec.
I'll happily trade IPSec for OpenVPN. ;-)
In any case, IPv6 should be enabled by default because users may connect to IPv6 networks and need it to "just work", just like IPv4. They aren't power users that know how to tweak hidden options, they just want to use the network.
To just use the network they need only IPv4. They don't need the security risks that current IPv6 implementation and default configurations adds. Today, IPv6 is far from "just works". You are advocating using all end users as guiena pigs for IPv6 evolution. I advocate evolving IPv6 before exposing end users to ti.
[]s, Fernando Lozano
Once upon a time, Fernando Lozano fernando@lozano.eti.br said:
If NAT prevents anyone from the internet to try to connect to my computer, this is increased security. After all, don't we configure firewalls exactly to prevent unwanted connections?
Use the firewall, ditch the NAT. NAT does not increase security over a firewall. In some cases, NAT prevents a user from accessing the Internet, rather than the other way around.
NAT is a fact today, has been for years, and people have been using Bittorrent and Skype regardless.
And sometimes they (and other applications) don't work, because of things like layered NAT.
For home users and SMBs, NAT is something that was taken care of. IPv6 is a whole new bunch of risks. I am not against IPv6 per se. I am against wide use of IPv6 right now. Let it mature.
How will it "mature" if nobody tries it? Fedora is a leading-edge operating system, and full IPv6 support is part of that.
As IPv4 runs out, some ISPs are turning to "Carrier Grade NAT", which adds layers of NAT that break things like P2P applications and IPSec.
I'll happily trade IPSec for OpenVPN. ;-)
That's nice, but in the real world, users have to connect to VPNs configured by others (and many businesses need hardware VPN concentrators, which OpenVPN won't work with).
To just use the network they need only IPv4.
That is not true in some places (and the number of such places is increasing all the time).
They don't need the security risks that current IPv6 implementation and default configurations adds. Today, IPv6 is far from "just works". You are advocating using all end users as guiena pigs for IPv6 evolution. I advocate evolving IPv6 before exposing end users to ti.
You are several years behind the curve on IPv6.
You keep talking about IPv6 security risks (over IPv4), but haven't cited any.
IPv6 does "just work" in many places; there are a lot of people that are using IPv6 and don't even know it (because they don't need to know; they just want to get to Facebook/Gmail/etc.). Fedora (and most Linux distributions I believe) have had IPv6 enabled-by-default for years; so have Mac OS X and Windows (even XP since IIRC SP2 will get an IPv6 autoconf address and use IPv6 transparently).
Whether you like it or not, IPv6 is here today and is here to stay. There is no practical alternative. Will there be bugs? Yes, of course; people are still finding IPv4 bugs as well.
On 07/11/2013 11:12 AM, Chris Adams wrote:
Use the firewall, ditch the NAT. NAT does not increase security over a firewall. In some cases, NAT prevents a user from accessing the Internet, rather than the other way around.
Can you give a practical example, please. I've no reason to disbelieve you, but I've also never run across such a case and would like to see one.
Once upon a time, Joe Zeff joe@zeff.us said:
On 07/11/2013 11:12 AM, Chris Adams wrote:
Use the firewall, ditch the NAT. NAT does not increase security over a firewall. In some cases, NAT prevents a user from accessing the Internet, rather than the other way around.
Can you give a practical example, please. I've no reason to disbelieve you, but I've also never run across such a case and would like to see one.
I've seen people with double-NAT issues before, where "special" protocols like FTP or game console can't traverse the double-NAT. Any newer attempted peer-to-peer protocol through an older NAT implementation that doesn't have ALGs for the protocol tends to fail (often in mysterious ways). IPsec through a NAT setup that doesn't have IPsec pass-through specifically enabled usually fails.
I can't give you personal examples because I don't use NAT for my stuff.
On 07/11/2013 12:12 PM, Chris Adams wrote:
I've seen people with double-NAT issues before, where "special" protocols like FTP or game console can't traverse the double-NAT.
I'm not quite sure what you mean here. Are you referring to having one router "behind" another, with both using NAT? I have a DSL modem that's supposed to act as a router, with two devices connected to it: a regular router and a WiFi router, both on separate subnets, both using NAT, and I've never had any problems with such things as FTP. Of course, my equipment probably doesn't have what you refer to as older implementations, so I may just be lucky.
In any event, thanx for the information.
On Thu, Jul 11, 2013 at 12:36:10PM -0700, Joe Zeff wrote:
On 07/11/2013 12:12 PM, Chris Adams wrote:
I've seen people with double-NAT issues before, where "special" protocols like FTP or game console can't traverse the double-NAT.
I'm not quite sure what you mean here. Are you referring to having one router "behind" another, with both using NAT? I have a DSL modem that's supposed to act as a router, with two devices connected to it: a regular router and a WiFi router, both on separate subnets, both using NAT, and I've never had any problems with such things as FTP. Of course, my equipment probably doesn't have what you refer to as older implementations, so I may just be lucky.
In any event, thanx for the information.
Some ISPs deploy something known as CGN (Carrier-Grade NAT) due the the IPv4 shortage, in which case if your "gateway" device at home is also doing NAT, you have double NAT.
On 07/11/2013 12:45 PM, staticsafe wrote:
Some ISPs deploy something known as CGN (Carrier-Grade NAT) due the the IPv4 shortage, in which case if your "gateway" device at home is also doing NAT, you have double NAT.
Gotcha. However, as my modem does NAT, I'm behind a double NAT. Maybe I'm just lucky or I'm not doing whatever it takes for this to show up. And again, it's good to know, Just In Case it shows up.
I turned on IPv6 in my router.
I am still getting 6to4 Tunnel from my ISP.
Netflix is currently streaming so my network is not idle.
I tried ping and ping6 anyway. This is NOT on an idle network.
rsewill@localhost:~ <3:3> $ ping www.google.com PING www.google.com (74.125.227.146) 56(84) bytes of data. 64 bytes from dfw06s17-in-f18.1e100.net (74.125.227.146): icmp_seq=1 ttl=52 time=46.0 ms 64 bytes from dfw06s17-in-f18.1e100.net (74.125.227.146): icmp_seq=2 ttl=52 time=45.6 ms 64 bytes from dfw06s17-in-f18.1e100.net (74.125.227.146): icmp_seq=3 ttl=52 time=50.1 ms 64 bytes from dfw06s17-in-f18.1e100.net (74.125.227.146): icmp_seq=4 ttl=52 time=44.9 ms 64 bytes from dfw06s17-in-f18.1e100.net (74.125.227.146): icmp_seq=5 ttl=52 time=62.3 ms ^C --- www.google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 44.947/49.834/62.398/6.538 ms rsewill@localhost:~ <3:3> $ ping6 www.google.com PING www.google.com(dfw06s17-in-x10.1e100.net) 56 data bytes 64 bytes from dfw06s17-in-x10.1e100.net: icmp_seq=1 ttl=54 time=119 ms 64 bytes from dfw06s17-in-x10.1e100.net: icmp_seq=2 ttl=54 time=120 ms 64 bytes from dfw06s17-in-x10.1e100.net: icmp_seq=3 ttl=54 time=121 ms 64 bytes from dfw06s17-in-x10.1e100.net: icmp_seq=4 ttl=54 time=117 ms 64 bytes from dfw06s17-in-x10.1e100.net: icmp_seq=5 ttl=54 time=117 ms 64 bytes from dfw06s17-in-x10.1e100.net: icmp_seq=6 ttl=54 time=119 ms ^C --- www.google.com ping statistics --- 7 packets transmitted, 6 received, 14% packet loss, time 6002ms rtt min/avg/max/mdev = 117.395/119.257/121.898/1.636 ms
There remains a performance penalty when using IPv6. As another pointed out, this is because of the path the packet is routed.
I trust Linux when I turn on IPv6. I can turn off most services and have the firewall on.
I don't know if I trust the Apple Mac or Windows when I turn on IPv6.
Given the ISP is handing out 6to4 tunneling, I still think the ISP support is "sort of not there".
My router has some IPv6 stuff in it. It has enough to turn on and use IPv6. My router is missing reporting stuff I would expect to find for IPv6. My router has a screen that reports attached devices and reports IPv4 stuff, not IPv6 stuff. I would say my router still needs some stuff to be IPv6 friendly.
I apologize for my earlier top postings. I use gmail and it likes to top post.
I am guessing, please correct me if I am wrong, IPv4 will be used in preference to IPv6, when both are available.
I am curious. Is there any recommended equivalent of speedtest.net for IPv6?
I have mixed feelings about disabling IPv6 or leaving IPv6 enabled. Each person must make this decision, on their own.
On Thu, Jul 11, 2013 at 02:20:37PM -0500, Richard Sewill wrote:
I turned on IPv6 in my router.
I am still getting 6to4 Tunnel from my ISP.
Netflix is currently streaming so my network is not idle.
I tried ping and ping6 anyway. This is NOT on an idle network.
There remains a performance penalty when using IPv6. As another pointed out, this is because of the path the packet is routed.
I trust Linux when I turn on IPv6. I can turn off most services and have the firewall on.
I don't know if I trust the Apple Mac or Windows when I turn on IPv6.
Given the ISP is handing out 6to4 tunneling, I still think the ISP support is "sort of not there".
My router has some IPv6 stuff in it. It has enough to turn on and use IPv6. My router is missing reporting stuff I would expect to find for IPv6. My router has a screen that reports attached devices and reports IPv4 stuff, not IPv6 stuff. I would say my router still needs some stuff to be IPv6 friendly.
I apologize for my earlier top postings. I use gmail and it likes to top post.
I am guessing, please correct me if I am wrong, IPv4 will be used in preference to IPv6, when both are available.
I am curious. Is there any recommended equivalent of speedtest.net for IPv6?
I have mixed feelings about disabling IPv6 or leaving IPv6 enabled. Each person must make this decision, on their own.
See RFC3484 [0], page 11, section "Destination Address Selection".
Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA.
Discussion: 6-over-4 [15], ISATAP [16], and configured tunnels [17] are examples of encapsulating transition mechanisms for which the destination address does not have a specific prefix and hence can not be assigned a lower precedence in the policy table. An implementation MAY generalize this rule by using a concept of interface preference, and giving virtual interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a lower preference than native interfaces (like ethernet interfaces).
In your case, getaddrinfo rules apply, IPv4 will be preferred over a 6to4 connection.
[0] - http://www.ietf.org/rfc/rfc3484.txt
Once upon a time, Richard Sewill rsewill@gmail.com said:
I tried ping and ping6 anyway. This is NOT on an idle network.
Since ICMP and ICMPv6 are low-priority, the data is not very useful. Also, since latency is only one component of throughput (and most communications are not particularly sensitive to latency less than about 200ms, except for issues like bufferbloat), this really doesn't mean much.
However, since we're going for anecdotal evidence, this is on an otherwise idle system on an uncongested link (and not using a tunnel):
$ ping -c5 www.google.com PING www.google.com (74.125.26.106) 56(84) bytes of data. 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=1 ttl=40 time=45.2 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=2 ttl=40 time=45.2 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=3 ttl=40 time=45.3 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=4 ttl=40 time=45.7 ms 64 bytes from vh-in-f106.1e100.net (74.125.26.106): icmp_seq=5 ttl=40 time=45.5 ms
--- www.google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4052ms rtt min/avg/max/mdev = 45.238/45.443/45.796/0.244 ms $ ping6 -c5 www.google.com PING www.google.com(vh-in-x6a.1e100.net) 56 data bytes 64 bytes from vh-in-x6a.1e100.net: icmp_seq=1 ttl=55 time=24.8 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=2 ttl=55 time=24.8 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=3 ttl=55 time=24.8 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=4 ttl=55 time=24.9 ms 64 bytes from vh-in-x6a.1e100.net: icmp_seq=5 ttl=55 time=24.9 ms
--- www.google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4033ms rtt min/avg/max/mdev = 24.819/24.878/24.909/0.202 ms
There remains a performance penalty when using IPv6.
No, there is possibly a performance issue with your ISP. Have you reported the problem?
Given the ISP is handing out 6to4 tunneling, I still think the ISP support is "sort of not there".
Lots of ISPs will probably use last-hop tunnels for a while, because a lot of the last-hop gear is old and doesn't properly support IPv6. Eventually that gear will be replaced, but in the interim, they'll install tunnel servers alongside the last-hop gear. It is possible your ISP doesn't have the tunnel server near your last-hop and is taking a sub-optimal path.
However, similar kinds of sub-optimal routing happen with IPv4 all the time, especially once MPLS comes in to play.
I am guessing, please correct me if I am wrong, IPv4 will be used in preference to IPv6, when both are available.
No, when both are available, IPv6 takes precedence (in general for modern applications that don't override the precedence); this is spelled out in several RFCs (can't recall the numbers). I think there is a global way to override this (maybe /etc/gai.conf can do it?).
On 07/11/2013 02:47 PM, Chris Adams wrote:
No, when both are available, IPv6 takes precedence (in general for modern applications that don't override the precedence); this is spelled out in several RFCs (can't recall the numbers). I think there is a global way to override this (maybe /etc/gai.conf can do it?).
You are correct with one exception. Glibc places 6-to-4 connections at a lower priority so IPv4 addresses are used over IPv6 in this case. You are also correct in that you can override this with gai.conf.
On Fri, Jul 12, 2013 at 4:43 AM, Joe Zeff joe@zeff.us wrote:
Can you give a practical example, please. I've no reason to disbelieve you, but I've also never run across such a case and would like to see one.
This kind of depends on what iptables or firewall rules you have, but for a moment lets assume that you allow "related" connections on your input.
What this means is to allow anything you connect outbound to to be trusted to make a reverse connection back to you.
So you are therefore trusting everything you connect to. Doesn't sound very "Secure" to me.
dave
Am 13.07.2013 00:45, schrieb David Beveridge:
On Fri, Jul 12, 2013 at 4:43 AM, Joe Zeff joe@zeff.us wrote:
Can you give a practical example, please. I've no reason to disbelieve you, but I've also never run across such a case and would like to see one.
This kind of depends on what iptables or firewall rules you have, but for a moment lets assume that you allow "related" connections on your input.
What this means is to allow anything you connect outbound to to be trusted to make a reverse connection back to you.
So you are therefore trusting everything you connect to. Doesn't sound very "Secure" to me
would you please be so kind and inform you instead spread FUD
how do you imagine that a UDP service answers since it is a stateless proctocol without the rule below?
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
*no* it does *not* open any incoming traffic to you - only *related*
what is related? the combination outgoing/incoming port/IP because if you start a connection your software chooses a random port above 1024 and the answer comes back to exactly this port
On Sat, Jul 13, 2013 at 8:55 AM, Reindl Harald h.reindl@thelounge.net wrote:
and the answer comes back to exactly this port https://en.wikipedia.org/wiki/Stateful_firewall
https://en.wikipedia.org/wiki/UDP_hole_punching "On some routers where port randomization is performed on a per-outbound host basis, the ports are not randomly selected, but actually sequential, making it possible to establish a conversation through guessing nearby ports."
Am 13.07.2013 02:34, schrieb David Beveridge:
On Sat, Jul 13, 2013 at 8:55 AM, Reindl Harald h.reindl@thelounge.net wrote:
and the answer comes back to exactly this port https://en.wikipedia.org/wiki/Stateful_firewall
https://en.wikipedia.org/wiki/UDP_hole_punching "On some routers where port randomization is performed on a per-outbound host basis, the ports are not randomly selected, but actually sequential, making it possible to establish a conversation through guessing nearby ports."
which is *completly* a different thing as you have statet before and i guess that is why you removed it from the quote...
Am 13.07.2013 02:34, schrieb David Beveridge:
On Sat, Jul 13, 2013 at 8:55 AM, Reindl Harald h.reindl@thelounge.net wrote:
and the answer comes back to exactly this port https://en.wikipedia.org/wiki/Stateful_firewall
https://en.wikipedia.org/wiki/UDP_hole_punching "On some routers where port randomization is performed on a per-outbound host basis, the ports are not randomly selected, but actually sequential, making it possible to establish a conversation through guessing nearby ports."
and *what* has a implementation mistake to do with your answer below which you stripped out as well as the context of my whole answer to let you look smarter?
but for a moment lets assume that you allow "related" connections on your input. What this means is to allow anything you connect outbound to to be trusted to make a reverse connection back to you
This kind of depends on what iptables or firewall rules you have, but for a moment lets assume that you allow "related" connections on your
input.
What this means is to allow anything you connect outbound to to be trusted to make a reverse connection back to you.
So you are therefore trusting everything you connect to. Doesn't sound very "Secure" to me.
That's not what related means...
Related refers to the returning flow for a given session (sequence numbers need to match etc) or in the case of ftp with the appropriate ftp conntrack module then the data channel related to the control channel TCP session currently open not that the destination can then connect willy nilly back to the source...
Allegedly, on or about 11 July 2013, Chris Adams sent:
You keep talking about IPv6 security risks (over IPv4), but haven't cited any.
While I don't know of security risks of IPv6, itself, there is this:
How is your firewall set up? When you allow something for IPv4, does it make a corresponding rule for IPv6, at the same time. Likewise, for if you block something. And I mean that in two ways, dealing with ports, and addresses. I may decide to block all port 80 traffic, and I'd hope my firewall doesn't just put a block on IPv4 traffic, requiring me to separately set up another rule for the IPv6. Or, I may find out that I'm seeing unwanted traffic from www.example.com, I'll probably have to find out their IPv4 and IPv6 IPs and individually block them.
I mean that question about firewall security in the general, as in anybody using a computer, not just my current version of Fedora.
Then there's address range types. With IPv4 it's easy enough to have a demarcation point between one side of my LAN and the WWW, and set rules about it. IPv6 uses a different technique of addressing/subnetting, and in some of my earlier readings of it, doesn't really work in a similar way that you can do that kind of demarcation. There's not that level of distinction between LAN and WAN.
So there's those basic levels of security, before anybody even worries about flaws in IPv6, itself.
Once upon a time, Tim ignored_mailbox@yahoo.com.au said:
How is your firewall set up? When you allow something for IPv4, does it make a corresponding rule for IPv6, at the same time. Likewise, for if you block something. And I mean that in two ways, dealing with ports, and addresses. I may decide to block all port 80 traffic, and I'd hope my firewall doesn't just put a block on IPv4 traffic, requiring me to separately set up another rule for the IPv6. Or, I may find out that I'm seeing unwanted traffic from www.example.com, I'll probably have to find out their IPv4 and IPv6 IPs and individually block them.
Except for trying to block things by hostname (which is always a problem, since DNS changes all the time), yes. My firewall does all of that. As far as I know, the CPE advertising IPv6 support does that. I'm pretty sure the Windows software firewall does that (don't know anything about Mac OS X).
Does _every_ firewall that claims IPv4 and IPv6 support do that correctly? I don't know, probably not. But at the same time, does every firewall that claims IPv4 support handle all of the above correctly, 100% of the time? Probably not. There will always be bugs, design flaws, etc.
Then there's address range types. With IPv4 it's easy enough to have a demarcation point between one side of my LAN and the WWW, and set rules about it. IPv6 uses a different technique of addressing/subnetting, and in some of my earlier readings of it, doesn't really work in a similar way that you can do that kind of demarcation. There's not that level of distinction between LAN and WAN.
Yes, IPv4 and IPv6 addresses are different (that's kind of the point). The whole idea that somehow RFC1918 space is "magic" (I hear people call it "unroutable" all the time, which is flat wrong) came in with NAT and is bad, as anybody who has dealt with enterprise networks (and especially when companies merge, interconnect, etc.) can tell you.
If you want something similar to RFC1918 space with IPv6, you can use ULA, but you really shouldn't.
So there's those basic levels of security, before anybody even worries about flaws in IPv6, itself.
I don't see anything here much other than "it is different and different is bad"; certinaly not any of the supposed "security flaws".
Am 12.07.2013 16:04, schrieb Chris Adams:
Once upon a time, Tim ignored_mailbox@yahoo.com.au said:
How is your firewall set up? When you allow something for IPv4, does it make a corresponding rule for IPv6, at the same time. Likewise, for if you block something. And I mean that in two ways, dealing with ports, and addresses. I may decide to block all port 80 traffic, and I'd hope my firewall doesn't just put a block on IPv4 traffic, requiring me to separately set up another rule for the IPv6. Or, I may find out that I'm seeing unwanted traffic from www.example.com, I'll probably have to find out their IPv4 and IPv6 IPs and individually block them.
Does _every_ firewall that claims IPv4 and IPv6 support do that correctly? I don't know, probably not.
* iptables and iptables6 are two different things * as long as my network has no public ipv6 addresses there is no need * i would have to tighten iptables6 rules 1:1 to iptables4 * my webserver must not access 127.0.0.1:445 * without ipv6 enabled i do not need to block it for ::1 and start to deal with iptables6 at all which would happen for this machine *after* a public ipv6 IP becomes a topic
so again: ipv6disable=1 has to disable the *entire* stack as it currently does with F17/F18 as long as *I* decide as admin that all components of the machine are ipv6-capable and *before* i set a AAA-record to the machine ______________________________________
the first lines on any of my machines to prevent os-fingerprinting and different port-scan methods which otherwise would be possible
how are looking these things like in ipv6?
i do not know and until i have on no network a public ipv6 address i do not need to know it
iptables -A INPUT ! -i lo -m conntrack --ctstate INVALID -j DROP iptables -A INPUT ! -i lo -p tcp -m conntrack --ctstate NEW --dport 0 -j DROP iptables -A INPUT ! -i lo -p udp -m conntrack --ctstate NEW --dport 0 -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ALL FIN -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ALL ALL -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ALL NONE -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags SYN,RST SYN,RST -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags FIN,RST FIN,RST -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ACK,FIN FIN -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ACK,PSH PSH -j DROP iptables -A INPUT ! -i lo -p tcp --tcp-flags ACK,URG URG -j DROP iptables -A INPUT ! -i lo -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
Hi,
You keep talking about IPv6 security risks (over IPv4), but haven't cited any.
While I don't know of security risks of IPv6, itself, there is this:
If you follow IPv6 on the net you should have found lots of articles about this, and how it affects specially home users and SMBs. Here are some introductory links:
http://thepcsecurity.com/ipv6-security-issues-concerns-transition/ http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-ac... http://searchsecurity.techtarget.com/tip/IPv6-myths-Debunking-misconceptions...
Most vendors and ISPs won't talk about his -- IPv6 is a selling point -- but here's buried inside an AT&T white paper:
http://www.webtorials.com/main/resource/papers/att/paper28/IPv6_impact_netwo...
"According to the National Institute of Standards and Technology (NIST): Prevention of unauthorized access to IPv6 networks will likely be more difficult in the early years of IPv6 deployments. IPv6 adds more components to be filtered than IPv4, such as extension headers, multicast addressing, and increased use of ICMP. These extended capabilities of IPv6, as well as the possibility of an IPv6 host having a number of global IPv6 addresses, potentially provides an environment that will make network-level access easier for attackers due to improper deployment of IPv6 access controls. Moreover, security related tools and accepted best practices have been slow to accommodate IPv6. Either these items do not exist or have not been stress tested in an IPv6 environment"
For more techinical content, you can visit
which is Fernando Gont home page (author of some IETF RFCs), and see theslides at
http://www.si6networks.com/presentations/ipv6kongress/mhfg-ipv6-kongress-ipv...
How is your firewall set up?
That's not the question. I am an experienced sysadmin and networking expert, I know where to search for information and what to look for. But today most computer users, not just Fedora users, do not have this expertise and won't spend enough time researching. They expect to get minimally secure default from vendors and open source projects. something most DO NOT provide currenty, regarding IPv6. :-(
The fact is: today, even most experienced network admins do not know enough about IPv6 security. Most ones I talked to still believe "IPv6 is more secure by design" which it isn't.
[]s, Fernando Lozano
Hi,
I took me time to recover this one, another more techinical content about IPv6 security:
http://w3.antd.nist.gov/iip_pubs/Montgomery-ipv6-security-findings.doc
[]s, Fernando Lozano
Hi,
You keep talking about IPv6 security risks (over IPv4), but haven't cited any.
While I don't know of security risks of IPv6, itself, there is this:
If you follow IPv6 on the net you should have found lots of articles about this, and how it affects specially home users and SMBs. Here are some introductory links:
http://thepcsecurity.com/ipv6-security-issues-concerns-transition/ http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-ac...
http://searchsecurity.techtarget.com/tip/IPv6-myths-Debunking-misconceptions...
Most vendors and ISPs won't talk about his -- IPv6 is a selling point -- but here's buried inside an AT&T white paper:
http://www.webtorials.com/main/resource/papers/att/paper28/IPv6_impact_netwo...
"According to the National Institute of Standards and Technology (NIST): Prevention of unauthorized access to IPv6 networks will likely be more difficult in the early years of IPv6 deployments. IPv6 adds more components to be filtered than IPv4, such as extension headers, multicast addressing, and increased use of ICMP. These extended capabilities of IPv6, as well as the possibility of an IPv6 host having a number of global IPv6 addresses, potentially provides an environment that will make network-level access easier for attackers due to improper deployment of IPv6 access controls. Moreover, security related tools and accepted best practices have been slow to accommodate IPv6. Either these items do not exist or have not been stress tested in an IPv6 environment"
For more techinical content, you can visit
which is Fernando Gont home page (author of some IETF RFCs), and see theslides at
http://www.si6networks.com/presentations/ipv6kongress/mhfg-ipv6-kongress-ipv...
How is your firewall set up?
That's not the question. I am an experienced sysadmin and networking expert, I know where to search for information and what to look for. But today most computer users, not just Fedora users, do not have this expertise and won't spend enough time researching. They expect to get minimally secure default from vendors and open source projects. something most DO NOT provide currenty, regarding IPv6. :-(
The fact is: today, even most experienced network admins do not know enough about IPv6 security. Most ones I talked to still believe "IPv6 is more secure by design" which it isn't.
[]s, Fernando Lozano
Hi,
NAT is a fact today, has been for years, and people have been using Bittorrent and Skype regardless.
And sometimes they (and other applications) don't work, because of things like layered NAT.
Fix NAT issues instead of ditch it altogether.
For home users and SMBs, NAT is something that was taken care of. IPv6 is a whole new bunch of risks. I am not against IPv6 per se. I am against wide use of IPv6 right now. Let it mature.
How will it "mature" if nobody tries it? Fedora is a leading-edge operating system, and full IPv6 support is part of that.
Fedora servers many different kinds of users, some of then are not network people and would be hurt by current IPv6 problems. The network people can enable IPv6, other should't have to disable it. That's the same principle as don't let TCP ports open by default on iptables.
As IPv4 runs out, some ISPs are turning to "Carrier Grade NAT", which adds layers of NAT that break things like P2P applications and IPSec.
I'll happily trade IPSec for OpenVPN. ;-)
That's nice, but in the real world, users have to connect to VPNs configured by others (and many businesses need hardware VPN concentrators, which OpenVPN won't work with).
In the real world, ISPs should fix their Carrier Grande NAT. There are lots of ways wrong network configs can 0impact apps.
To just use the network they need only IPv4.
That is not true in some places (and the number of such places is increasing all the time).
Defaults should focus most users, not the exceptions. When most users need IPv6, it's ok to have it enabled by default.
Plese note I ain't proposing removing IPv6 support from the Fedora Linux Kernel. I'm just proposing the default network configurations should have IPv6 disabled, and those who want to use it should have to take action (just click a checkbox) to enable.
They don't need the security risks that current IPv6 implementation and default configurations adds. Today, IPv6 is far from "just works". You are advocating using all end users as guiena pigs for IPv6 evolution. I advocate evolving IPv6 before exposing end users to ti.
You are several years behind the curve on IPv6.
You keep talking about IPv6 security risks (over IPv4), but haven't cited any.
Please see my other message about them, won't repeat the links here. You could just google "IPv6 security risks" to see articles from the current year about then. And follow IETF RFCs to see how many proposals about them are in Draft and not implement by most products yet. PLease don't assume people who disagree with you no clue what they are talking about.
IPv6 does "just work" in many places; there are a lot of people that are using IPv6 and don't even know it
And those are exposed to the security risks. We haven't see a high-profile (media coverage) IPv6 attach yet just because so few peple actually use it that it's not very attractive to hackers. But as ISPs move on implements proper IPv6 support (without tunnels internally) those ISP users are becoming so vulnerable.
Whether you like it or not, IPv6 is here today and is here to stay. There is no practical alternative. Will there be bugs? Yes, of course; people are still finding IPv4 bugs as well.
Will tell again: I'm bot against IPv6 per se. I agree it has to be deployed. But I can't agree using end users and SMBs as guinea pigs, waiting to see how hackers use it to create new attacks. Let the big companies work this before giving IPv6 enabled by default in Fedora, Windows, Mac and other OSes.
[]s, Fernando Lozano
Tim:
If manufacturers and software programmers don't pull their fingers out, we'll be faced with even more ISPs subjecting their clients to NAT.
Fernando Lozano:
Would this be so bad? Most people at work have been working using NAT for years. NAT increases security. Most internet users don't need to run servers.
Yes it would. NAT doesn't really increase security. It gives the illusion of doing so, because it usually breaks networking, but not always (just one reason why you shouldn't pretend it's a firewall).
Users do things that act like servers, and require connections to get through to them. It's hard enough with firewalls, and your own NAT that you can configure. When it's something outside of your control, it may become impossible.
Just a few things that become nightmarish with NAT:
Using some FTP servers. Sending files through instant messenger clients. Voice over IP. Using any type of peer-to-peer software.
Hi,
Tim:
If manufacturers and software programmers don't pull their fingers out, we'll be faced with even more ISPs subjecting their clients to NAT.
Fernando Lozano:
Would this be so bad? Most people at work have been working using NAT for years. NAT increases security. Most internet users don't need to run servers.
Yes it would. NAT doesn't really increase security. It gives the illusion of doing so, because it usually breaks networking, but not always (just one reason why you shouldn't pretend it's a firewall).
IMHO globaly-addressable client devices increase security risks. NAT make some things more complicated, but I'd rather improve NAT technologies and application protocols to work with then. Many experts argue in favor of NAT even for IPv6 networks, see for example:
http://searchenterprisewan.techtarget.com/tip/Why-IPv6-wont-rid-the-Internet...
Users do things that act like servers, and require connections to get through to them.
IMHO they shouldn't. End users will never know enough to implement proper network security. Cloud services would provide better alternatives to most "server-like" things users would want to do, with cheap and free options.
Just a few things that become nightmarish with NAT:
Using some FTP servers.
It's a protocol broken by design, with connection call-back connections. I'd eliminate FTP altogether.
Sending files through instant messenger clients.
Put Dropbox, Google Drive or the like suppport in IM clients. Push for a standard REST API for this kind of services, so IM developers don't have to write code for a myriad different services.
Voice over IP.
Improve VoIP protocols. Most VoIP users will anyway depend on centralized servers for realiability (like Skype supernodes), presence, authentication, or interoperability with POTS and cell services.
Using any type of peer-to-peer software.
IMHO peer-to-peer in general is a boken concept. It's nice for experimentation, good for politics (you won't depend on a big corporation) but increases network security risk. There are technical alternatives to peer-to-peer designs that IMHO lend to better security and QoS. On the political side, standards and ONGs should prevent dominance by big corporations.
Cloud VPN services would allow end-users to get connections to their home machines if they want, at the same without exposing them to scans and attacks from the whole Internet. I'd focus on improving those offering.
[]s, Fernando Lozano