Re: DHCPv6 *still* broken for F17 alpha
Le Sam 17 mars 2012 00:51, Glen Turner a écrit : On 2012-03-15 Dan Williams wrote: The only effect this checking will have is to change NetworkManager's state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It doesn't do anything odd like disconnect and retry some other connection, which wouldn't make much sense. It just changes some state which apps can use to figure out whether they'd connect to say your IRC server or your email or whatever automatically. I suggest that is something the application should determine, not NetworkManager. BTW, the proposed solution does not even work for http/s properly, let alone for other protocols -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
Le Lun 19 mars 2012 10:17, Nicolas Mailhot a écrit : Le Sam 17 mars 2012 00:51, Glen Turner a écrit : On 2012-03-15 Dan Williams wrote: The only effect this checking will have is to change NetworkManager's state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It doesn't do anything odd like disconnect and retry some other connection, which wouldn't make much sense. It just changes some state which apps can use to figure out whether they'd connect to say your IRC server or your email or whatever automatically. I suggest that is something the application should determine, not NetworkManager. BTW, the proposed solution does not even work for http/s properly, let alone for other protocols Forgot this: https://bugzilla.mozilla.org/show_bug.cgi?id=728658 -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Dan Williams On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote: The current behaviour of tearing down working IPv6 connections is just painful IMHO. If the IPv6 method is ignore (which is the current default) then NM shouldn't be touching IPv6 stuff on that interface; kernel-assigned routes and addresses should be there and untouched by NM. Is that not the case? For WiFi, no. When timing out DHCPv4 and failing the connection, NM takes the entire interface, along with any working IPv6 connectivity, down with it. (Also, on WiFi, it appears the default IPv6 method has been Automatic for quite some time.) (Of course, this entire discussion is now moot.) -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
Hi Dan, * Dan Williams On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: That is true, however, if IPv6 completes first, and IPv4 (still running in the background) eventually ends up failing, the *entire connection* will be torn down - including the perfectly working IPv6 connectivity. So the successfully connected state only lasts for about 20 seconds. I've gone back and forth on this last week; since it changes the default, it would break the case where somebody depends on the current behavior, ie that by default IPv4 may not fail. After this patch is applied, a network where IPv6 connectivity is available but broken (or where the router sends RAs with private prefixes like fdxx::) and IPv4 is for some reason also broken, will make NM show connected when in fact we aren't really. The new connectivity detection will help that somewhat, but we haven't enabled it by default yet for a few reasons. I ran into a network when testing this that caused me to think harder about this patch. It's an Actiontec router attached to Comcast (I think) but has no upstream IPv6 connectivity. It sends RAs for the fdxx:: address space and NM dutifully picks that up. So now we've got IPv6 connectivity to a private prefix that's not routable. If, in this case, the router's DHCP server died, which sometimes happens on crappy consumer hardware, an upgraded NM would report connected while old NMs would fail the connection. Whether we care enough about this regression (if you want to call it that) versus enabling default IPv6 connectivity I don't know, I tend to think we suck up the regression. But I'm still interested in the failure cases. So what you have here is a double failure, of sorts. First, your DHCPv4 service is broken, and second, your IPv6 service is broken too, but in a way that doesn't stop RAs. You'd like the connection activation to fail in this case. But what do you really accomplish? The systray icon will say not connected, which may be somewhat useful, but on the other hand, by allowing it to say connected instead, the user is really not any worse off - his browser (or whatever application will give him error messages in both cases, and he won't get to do what he wants to do. Besides, conceptually, this error isn't any different from another one that doesn't involve IPv6 at all. Let's say that the DHCPv4 server in your home gateway router works beautifully, but that its upstream DOCSIS/DSL/fibre/whatever link doesn't. (Having myself been on DSL for a number of years, I'll be damned if this is not something that happens *way* more frequently than the scenario you outlined above.) If you want to be consistent in not activating the network connection when internet connectivity doesn't work, you'd have to make sure the connection fails in this case too, right? But you don't, you allow the connection to succeed without the internet connectivity working. Which leaves the user in the exact same place as the guy behind the Actiontec. It's been like this for, like, forever. And somehow, the sky hasn't fallen yet. :-) However, if you turn it around, the guy behind the Actiontec with the defective DHCPv4 server might actually have working IPv6 connectivity, or at least he will have soon - Comcast is one of the leading ISPs in the world when it comes to IPv6 deployment. Do you really want to leave him without *any* connectivity in this case, or is it better to leave IPv4 failed but IPv6 working? Remember, with the entire connection failed, he can't get anywhere at all. With IPv6 still working, he'll be able to get to Google and try to find out what is going on, he'll probably be able to get to Comcast's customer portal to request assistance, or simply to hit Facebook to kill some time. That has got to be much better than having no connectivity at all, agreed? And, finally, that IPv6-only networks are a perfectly valid configuration is undisputable. Requiring IPv4 breaks those, too. The way I see it, what you gain by not allowing IPv4 to fail is providing the user with more clear error message in the case of a very narrow failure scenario. You don't actually fix or work around the problem in any way. Furthermore, you break other valid configurations, and aggravate other narrow failure scenarios. It's clearly not worth it, in my opinion. I know my patch is already in NM git, so I just wanted to send you this message mostly so you can sleep easy at night - convince you it was the right thing to do. :-) Thank you again! Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 right?) should NM say that we're only connected to a site-local network here? That would at least help the situation above, and indicate that something went wrong instead of NM saying we're connected to the internet and nothing working. Yes and no. On their own, Unique Local Addresses (fd00::/7) addresses needs NAT66, proxies, or something along those lines to get the user on the
Re: DHCPv6 *still* broken for F17 alpha
* Petr Pisar How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope address in IPv4 is Ok, while getting such address in IPv6 is considered as failure? Just a little comment regarding the terminology used here. The terms global, site, and link scope have very specific and defined meanings in IPv6. If you run /sbin/ip -6 address list you will see that all the addresses returned include their scope. You can also select addresses by their scope (e.g. do stuff like /sbin/ip -6 address flush scope global). ULAs, fd00::/7, explicitly have a global scope. This is because their reachability is not restricted to a single organisation or site - one of the main features of ULAs compared to site-scoped addresses are that even though they won't be seen on the public internet, two separate organisations can very well connect using VPNs or private interconnects and use their own separate ULA prefixes to communicate. In other words, the scope of ULA addresses are defined by the routing and network topology around them, not by the actual addresses themselves. Look at RFC 4193 for more details (in particular section 3.3). This means that if NM's connectivity check were to report that it had site connectivity when only having ULA addresses configured, it would actually be incorrect as far as IPv6 terminology goes. It would be more correct to say not internet or something along those lines. Best regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 2012-03-15 Dan Williams wrote: The only effect this checking will have is to change NetworkManager's state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It doesn't do anything odd like disconnect and retry some other connection, which wouldn't make much sense. It just changes some state which apps can use to figure out whether they'd connect to say your IRC server or your email or whatever automatically. Hi Dan, I suggest that is something the application should determine, not NetworkManager. Take the case where a ISP loses international connectivity, then a NetworkManager-informed application won't connect to the in-country ISP's IRC/e-mail/... server even though those servers are available. Thus connectivity detection worsens a partial loss of connectivity into a full loss of connectivity. The app has to be able to handle no connectivity anyway: just because Network Manager can HTTP GET the URI doesn't mean that IRC works. For example, a corporate firewall could allow HTTP but block IRC. Both the end-to-end argument and occam's razor argue for the application gracefully handling no connectivity. The current situation is that many apps don't handle a lack of connectivity with grace. But I suggest that this isn't NetworkManager's problem to solve. Even the current situation isn't great. NetworkManager shouldn't be telling applications that the network is available. That DBUS message should be triggered by the insertion into the main forwarding table of a default route. Then any source of global connectivity will set the app connecting (NM, NM work alikes, ip route add, ospfd, tunnels, etc). Best wishes, Glen PS: I really don't understand the operation of dnssec-triggerd. The paths for HTTP and DNS traffic through an enterprise network can be very different so testing one protocol doesn't say a huge amount about the availability of the other protocol. But then I don't even understand the desirability of that program: allowing an external event (eg an access list on a router or a DoS attack) to trigger a reconfiguration from a DNSSEC-validating to a non-validating configuration seems more of a security bug than a feature. But I'm likely missing something here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 2012-03-14, Dan Williams d...@redhat.com wrote: On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: * Dan Williams 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. That is true, however, if IPv6 completes first, and IPv4 (still running in the background) eventually ends up failing, the *entire connection* will be torn down - including the perfectly working IPv6 connectivity. So the successfully connected state only lasts for about 20 seconds. A trivial patch that fixes this problem is attached, please apply. I've gone back and forth on this last week; since it changes the default, it would break the case where somebody depends on the current behavior, ie that by default IPv4 may not fail. After this patch is applied, a network where IPv6 connectivity is available but broken (or where the router sends RAs with private prefixes like fdxx::) and IPv4 is for some reason also broken, will make NM show connected when in fact we aren't really. The new connectivity detection will help that somewhat, but we haven't enabled it by default yet for a few reasons. How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope address in IPv4 is Ok, while getting such address in IPv6 is considered as failure? Unfortunatelly companies expect deploying NAT66 (network multihoming while missing access to BGP). Also user may expect installation from local mirror or through proxy. I think you are doing the installer to much smart resulting in crappy behaviour in special cases. If you want to check connectivy, let's ping official Fedora mirror. Present the ping result to user as a hint, but do not prevent him from proceding. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote: On Wednesday 14 March 2012 13:36:06 Dan Williams wrote: Whether we care enough about this regression (if you want to call it that) versus enabling default IPv6 connectivity I don't know, I tend to think we suck up the regression. Please do. The current behaviour of tearing down working IPv6 connections is just painful IMHO. If the IPv6 method is ignore (which is the current default) then NM shouldn't be touching IPv6 stuff on that interface; kernel-assigned routes and addresses should be there and untouched by NM. Is that not the case? Dan Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 right?) should NM say that we're only connected to a site-local network here? That's probably the best thing to do, in both cases, IPv4 and IPv6. What NM definitely should not do is say that the connection failed while it's perfectly connected to a local network where there is just no link to the internet. Thanks, Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 2012-03-15 at 10:07 +, Petr Pisar wrote: On 2012-03-14, Dan Williams d...@redhat.com wrote: On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: * Dan Williams 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. That is true, however, if IPv6 completes first, and IPv4 (still running in the background) eventually ends up failing, the *entire connection* will be torn down - including the perfectly working IPv6 connectivity. So the successfully connected state only lasts for about 20 seconds. A trivial patch that fixes this problem is attached, please apply. I've gone back and forth on this last week; since it changes the default, it would break the case where somebody depends on the current behavior, ie that by default IPv4 may not fail. After this patch is applied, a network where IPv6 connectivity is available but broken (or where the router sends RAs with private prefixes like fdxx::) and IPv4 is for some reason also broken, will make NM show connected when in fact we aren't really. The new connectivity detection will help that somewhat, but we haven't enabled it by default yet for a few reasons. How does fd00::/16 differes from 10.0.0.0/8? Why getting site scope address in IPv4 is Ok, while getting such address in IPv6 is considered as failure? Unfortunatelly companies expect deploying NAT66 (network multihoming while missing access to BGP). Also user may expect installation from local mirror or through proxy. I think you are doing the installer to much smart resulting in crappy behaviour in special cases. If you want to check connectivy, let's ping official Fedora mirror. Present the ping result to user as a hint, but do not prevent him from proceding. The current connectivity checking code is built-but-inactive in F17, you can enable it by adding these entries to /etc/NetworkManager/NetworkManager.conf: [connectivity] uri=http://url interval=120 the URL is expected to return one or both of: 1) an HTTP header named X-NetworkManager-Status with the value of online 2) an document body consisting only of the text NetworkManager is online (can be customized by an option in the config file) This method lets NM (in the future) detect captive portals and will allow auto-login in those networks. It's basically what Windows does for its connectivity detection too. If we have proxy information, in the near future we'd use it here as well. If NM doesn't get the correct response then for the most part, we can't consider the machine to have Internet connectivity. Obviously this can be disabled (by not specifying a connectivity check URI) for cases where it's known not to work. The only effect this checking will have is to change NetworkManager's state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL. It doesn't do anything odd like disconnect and retry some other connection, which wouldn't make much sense. It just changes some state which apps can use to figure out whether they'd connect to say your IRC server or your email or whatever automatically. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 15 Mar 2012, Dan Williams wrote: The current connectivity checking code is built-but-inactive in F17, you can enable it by adding these entries to /etc/NetworkManager/NetworkManager.conf: [connectivity] uri=http://url interval=120 the URL is expected to return one or both of: 1) an HTTP header named X-NetworkManager-Status with the value of online 2) an document body consisting only of the text NetworkManager is online (can be customized by an option in the config file) This method lets NM (in the future) detect captive portals and will Note that such a scheme has already been setup for other software at: http://fedoraproject.org/static/hotspot.txt It returns OK and is guaranteed never to do any redirects, so you can detect hotspots. dnssec-triggerd will use this but we hope this functionality will go into NM itself, so that NM can actually run dnssec-trigger-control commands directly, and incorporate all the gui elements from dnssec-trigger-panel. to understand my babbling, yum install dnssec-trigger, start dnssec-trigger-panel, see probe, probe results and hotspot mode I am looking forward to the day that only dnssec-triggerd (or its incorporation into NM) will touch /etc/resolv.conf Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: * Dan Williams 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. That is true, however, if IPv6 completes first, and IPv4 (still running in the background) eventually ends up failing, the *entire connection* will be torn down - including the perfectly working IPv6 connectivity. So the successfully connected state only lasts for about 20 seconds. A trivial patch that fixes this problem is attached, please apply. I've gone back and forth on this last week; since it changes the default, it would break the case where somebody depends on the current behavior, ie that by default IPv4 may not fail. After this patch is applied, a network where IPv6 connectivity is available but broken (or where the router sends RAs with private prefixes like fdxx::) and IPv4 is for some reason also broken, will make NM show connected when in fact we aren't really. The new connectivity detection will help that somewhat, but we haven't enabled it by default yet for a few reasons. I ran into a network when testing this that caused me to think harder about this patch. It's an Actiontec router attached to Comcast (I think) but has no upstream IPv6 connectivity. It sends RAs for the fdxx:: address space and NM dutifully picks that up. So now we've got IPv6 connectivity to a private prefix that's not routable. If, in this case, the router's DHCP server died, which sometimes happens on crappy consumer hardware, an upgraded NM would report connected while old NMs would fail the connection. Whether we care enough about this regression (if you want to call it that) versus enabling default IPv6 connectivity I don't know, I tend to think we suck up the regression. But I'm still interested in the failure cases. Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 right?) should NM say that we're only connected to a site-local network here? That would at least help the situation above, and indicate that something went wrong instead of NM saying we're connected to the internet and nothing working. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wednesday 14 March 2012 13:36:06 Dan Williams wrote: Whether we care enough about this regression (if you want to call it that) versus enabling default IPv6 connectivity I don't know, I tend to think we suck up the regression. Please do. The current behaviour of tearing down working IPv6 connections is just painful IMHO. Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8 right?) should NM say that we're only connected to a site-local network here? That's probably the best thing to do, in both cases, IPv4 and IPv6. What NM definitely should not do is say that the connection failed while it's perfectly connected to a local network where there is just no link to the internet. Thanks, Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/02/2012 11:31 PM, Tore Anderson wrote: * Tom Callaway On 03/02/2012 04:39 PM, Tore Anderson wrote: This one *most likely* works (it assumes /sbin/dhclient in Fedora will *always* use a link-local source address when building a DHCPv6 request. I believe that is the case, but I have not reviewed its source code to verify): ip6tables -A INPUT -p udp --dport 546 -d fe80::/64 -j ACCEPT Can you please confirm that in the source code? I agree that this seems like the better option. Hi again, I've been poking around in the ISC-dhcp code for a while now, but I think I don't have sufficient C skills to follow what is going on 100%. I *think* it doesn't specify the source address anywhere, leaving it up to either glibc or the kernel to pick one when the packet is put on the wire. The ff02::1:2 multicast address (All_DHCP_Relay_Agents_and_Servers) has the link-local scope, so if the entity doing source address selection (be it the kernel or glibc) implements RFC 3484 correctly, the link-local source should be chosen, due to the the prefer matching scope rule. (If that didn't come into play, the prefer longest common prefix rule would also have ensured the link-local address was used for the source.) On my own system, where the interface is configured both with a link-local address and a global address (from SLAAC) at the time DHCPv6 is invoked, the link-local address is being used (so the -d fe80::/64 restriction works for me). So, based on observed behaviour, my reading of the IETF standards, and the fact that I cannot find anything that would suggest otherwise in the ISC dhcp sources; my estimate is that it's95% certain that including -d fe80::/64 will work in all cases. Or, to put it another way, it's ∞ better than what we have today, and since I assume people would be more comfortable with including that particular restriction in an enabled-by-default ip6tables exception, I say go for it. If it turns out there's someone out there it won't work for, then we can consider changing the rule (or the DHCPv6 client). Best regards, For firewalld we added the dhcpv6-client service in the GIT repo and it is part of the 'work' and 'home' zone already. I will also add it to the 'public' zone (the default zone) and the 'internal' zone for the F-17 package. The dhcpv6-client service adds the rule -p udp --dport 546 -d fe80::/64 -j ACCEPT Regards, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Dan Williams 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. That is true, however, if IPv6 completes first, and IPv4 (still running in the background) eventually ends up failing, the *entire connection* will be torn down - including the perfectly working IPv6 connectivity. So the successfully connected state only lasts for about 20 seconds. A trivial patch that fixes this problem is attached, please apply. Best regards, -- Tore Anderson diff --git a/libnm-util/nm-setting-ip4-config.c b/libnm-util/nm-setting-ip4-config.c index db5a531..54cf036 100644 --- a/libnm-util/nm-setting-ip4-config.c +++ b/libnm-util/nm-setting-ip4-config.c @@ -1231,7 +1231,7 @@ nm_setting_ip4_config_class_init (NMSettingIP4ConfigClass *setting_class) this property to TRUE allows the overall network configuration to succeed if IPv4 configuration fails but IPv6 configuration completes successfully., - FALSE, + TRUE, G_PARAM_READWRITE | G_PARAM_CONSTRUCT | NM_SETTING_PARAM_SERIALIZE)); } diff --git a/src/settings/plugins/ifcfg-rh/reader.c b/src/settings/plugins/ifcfg-rh/reader.c index eedd460..239eac5 100644 --- a/src/settings/plugins/ifcfg-rh/reader.c +++ b/src/settings/plugins/ifcfg-rh/reader.c @@ -1266,7 +1266,7 @@ make_ip4_setting (shvarFile *ifcfg, NM_SETTING_IP4_CONFIG_IGNORE_AUTO_DNS, !svTrueValue (ifcfg, PEERDNS, TRUE), NM_SETTING_IP4_CONFIG_IGNORE_AUTO_ROUTES, !svTrueValue (ifcfg, PEERROUTES, TRUE), NM_SETTING_IP4_CONFIG_NEVER_DEFAULT, never_default, - NM_SETTING_IP4_CONFIG_MAY_FAIL, !svTrueValue (ifcfg, IPV4_FAILURE_FATAL, TRUE), + NM_SETTING_IP4_CONFIG_MAY_FAIL, !svTrueValue (ifcfg, IPV4_FAILURE_FATAL, FALSE), NULL); if (strcmp (method, NM_SETTING_IP4_CONFIG_METHOD_DISABLED) == 0) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
Hi, * Adam Williamson If there's a bug against this, it could be nominated as a Beta or Final blocker. Here's a few: https://bugzilla.redhat.com/show_bug.cgi?id=538499 https://bugzilla.redhat.com/show_bug.cgi?id=552099 https://bugzilla.redhat.com/show_bug.cgi?id=591630 https://bugzilla.redhat.com/show_bug.cgi?id=656315 https://bugzilla.redhat.com/show_bug.cgi?id=656334 https://bugzilla.redhat.com/show_bug.cgi?id=712003 https://bugzilla.redhat.com/show_bug.cgi?id=798697 The problem has been known for four straight releases. I say it's time to fix it, before F17 becomes the fifth. It'd be a conditional breach of the 'must be able to connect to the network and install updates' criterion - the condition being 'IPv6 only network'. So that would mean we'd kick around how significant the 'IPv6 only network' case is, and whether it's yet big enough that we can consider a bug in that path a release blocker. I wouldn't want to predict the outcome of such a discussion, but it might well be worth having. +1 for considering IPv6-only significant. The lack of out of the box support for IPv6-only is really killing any possibility migrating away from IPv4 in our corporate client networks, where we have a bring your own device philosophy (we don't centrally manage people's laptops and therefore can't change bad defaults). We really need to get IPv6 deployed, as we are running dangerously short on IPv4 addresses - it isn't easy to get additional allocations from the RIPE NCC these days, either (and in a few months it's expected to be completely impossible as they'll have none left). The patches required to actually fix this problem exist and they really are trivial and non-intrusive. It's not like finally fixing this problem will delay the F17 release in any way. Heck, I'd wager that the time wasted on this very thread and the related bug reports are orders of magnitude more than the time it would take to actually apply the patches and be done with it. Looking forward, we might at some point want to explicitly 'support' IPv6 in the release criteria, by specifying that 'connect to the network' means all permutations of IPv4 / IPv6 networks should work... Yes please. Besides, you promised as much in the F12 release notes... Regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Tom Callaway As a temporary fix until the more complete service entry can be added, I propose this patch. Anaconda invokes: /usr/sbin/lokkit --quiet --nostart -f This writes out the default firewall, where everything is locked down, except for the hardcoded rules in system-config-firewall (ESTABLISHED,RELATED, lo, ipv6-icmp). I simply added the dhcpv6 accept to those hardcoded rules. The obvious downside to this approach is that dhcpv6 connections will always be explicitly accepted in generated ip6tables from the system-config-firewall tools, for all network devices, and users that want to change that will need to manually edit /etc/sysconfig/ip6tables. I agree completely that such a rule should be included by default in /etc/sysconfig/ip6tables for now. That said, regarding the actual rule you're proposing, I have some comments: * --sport 546 won't work, as the DHCPv6 server might not use its listening port when transmitting DHCPv6 replies. My DSL router (a ZyXEL P2812) does not, as shown in this tcpdump: 13:40:37.146507 IP6 fe80::21c:bfff:fe02:f2a5.dhcpv6-client ff02::1:2.dhcpv6-server: dhcp6 inf-req 13:40:37.147883 IP6 fe80::ca6c:87ff:feab:d027.51300 fe80::21c:bfff:fe02:f2a5.dhcpv6-client: dhcp6 reply * -s fe80::/10 is not guaranteed to work, the way I read the RFC. There is no requirement that the DHCPv6 replies transmitted by the server or relay needs to be sourced from a link-local address. It works for me, but I believe another server/relay implementation could use, say, its globally scoped unicast address as source when transmitting the replies, and still be conforming with the standard. * -d fe80::/10 might be guaranteed to work for Fedora - I believe it depends on the client behaviour. The server/relay is supposed to send the replies back to the source address of the initial request, and I don't see any requirement that the client needs to use its link-local address as the source when transmitting the request. Keep in mind that the requesting node may have acquired a global address from SLAAC before NetworkManager kicks off the DHCPv6 transaction. That said, SLAAC is used on my network, but the client used the link-local address for the request anyway, which makes -d fe80::/10 safe. Whether or not the DHCPv6 client will *always* use a link-local source address, however, is something I guess you'd have to review the source code to verify. Best regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/02/2012 03:59 PM, Tore Anderson wrote: * Tom Callaway As a temporary fix until the more complete service entry can be added, I propose this patch. Anaconda invokes: /usr/sbin/lokkit --quiet --nostart -f This writes out the default firewall, where everything is locked down, except for the hardcoded rules in system-config-firewall (ESTABLISHED,RELATED, lo, ipv6-icmp). I simply added the dhcpv6 accept to those hardcoded rules. The obvious downside to this approach is that dhcpv6 connections will always be explicitly accepted in generated ip6tables from the system-config-firewall tools, for all network devices, and users that want to change that will need to manually edit /etc/sysconfig/ip6tables. I agree completely that such a rule should be included by default in /etc/sysconfig/ip6tables for now. That said, regarding the actual rule you're proposing, I have some comments: comments snipped I know less than nothing about DHCPv6. I used the rule offered earlier in the thread by Paul Wouters. If there is a more appropriate ruleset, please tell me what it is and I'll regenerate the patch. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Fri, 2012-03-02 at 15:22 +0100, Tore Anderson wrote: Looking forward, we might at some point want to explicitly 'support' IPv6 in the release criteria, by specifying that 'connect to the network' means all permutations of IPv4 / IPv6 networks should work... Yes please. Besides, you promised as much in the F12 release notes... I'm _pretty_ sure I didn't write those. =) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Tom Callaway I know less than nothing about DHCPv6. I used the rule offered earlier in the thread by Paul Wouters. If there is a more appropriate ruleset, please tell me what it is and I'll regenerate the patch. This one will certainly work (it's the patch attached bug #591630): ip6tables -A INPUT -p udp --dport 546 -j ACCEPT This one *most likely* works (it assumes /sbin/dhclient in Fedora will *always* use a link-local source address when building a DHCPv6 request. I believe that is the case, but I have not reviewed its source code to verify): ip6tables -A INPUT -p udp --dport 546 -d fe80::/64 -j ACCEPT Also, the latter one might be much more desirable from a security standpoint, as it prevents random people/attackers on the internet from transmitting unsolicited packets to the DHCPv6 client. In order to successfully transmit a packet to a node using its link-local address in fe80::/64 as the destination address, you'll have to be on the same link. And if you have an attacker on the same link, you're dead anyway - matching the source address and/or source port adds nothing, those are trivially spoofed. Also, I removed the -m state --state NEW part, as I don't think doing a stateful match on the packet adds anything but processing overhead. After all, the reason for adding an explicit exception for DHCPv6 is that it *can't* be successfully matched by the current ip6tables state module. But I have no problems with it being included either, if it makes anyone happier. Best regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Adam Williamson Yes please. Besides, you promised as much in the F12 release notes... I'm _pretty_ sure I didn't write those. =) I meant «you» as in «The Fedora Project». ;-) -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/02/2012 04:39 PM, Tore Anderson wrote: This one *most likely* works (it assumes /sbin/dhclient in Fedora will *always* use a link-local source address when building a DHCPv6 request. I believe that is the case, but I have not reviewed its source code to verify): ip6tables -A INPUT -p udp --dport 546 -d fe80::/64 -j ACCEPT Can you please confirm that in the source code? I agree that this seems like the better option. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Tom Callaway On 03/02/2012 04:39 PM, Tore Anderson wrote: This one *most likely* works (it assumes /sbin/dhclient in Fedora will *always* use a link-local source address when building a DHCPv6 request. I believe that is the case, but I have not reviewed its source code to verify): ip6tables -A INPUT -p udp --dport 546 -d fe80::/64 -j ACCEPT Can you please confirm that in the source code? I agree that this seems like the better option. Hi again, I've been poking around in the ISC-dhcp code for a while now, but I think I don't have sufficient C skills to follow what is going on 100%. I *think* it doesn't specify the source address anywhere, leaving it up to either glibc or the kernel to pick one when the packet is put on the wire. The ff02::1:2 multicast address (All_DHCP_Relay_Agents_and_Servers) has the link-local scope, so if the entity doing source address selection (be it the kernel or glibc) implements RFC 3484 correctly, the link-local source should be chosen, due to the the prefer matching scope rule. (If that didn't come into play, the prefer longest common prefix rule would also have ensured the link-local address was used for the source.) On my own system, where the interface is configured both with a link-local address and a global address (from SLAAC) at the time DHCPv6 is invoked, the link-local address is being used (so the -d fe80::/64 restriction works for me). So, based on observed behaviour, my reading of the IETF standards, and the fact that I cannot find anything that would suggest otherwise in the ISC dhcp sources; my estimate is that it's 95% certain that including -d fe80::/64 will work in all cases. Or, to put it another way, it's ∞ better than what we have today, and since I assume people would be more comfortable with including that particular restriction in an enabled-by-default ip6tables exception, I say go for it. If it turns out there's someone out there it won't work for, then we can consider changing the rule (or the DHCPv6 client). Best regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/03/2012 03:11 AM, Tore Anderson wrote: * Adam Williamson Yes please. Besides, you promised as much in the F12 release notes... I'm _pretty_ sure I didn't write those. =) I meant «you» as in «The Fedora Project». ;-) It's not a promise. Its a bug in the documentation. Happens occasionally. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 1 Mar 2012, Dan Williams wrote: On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is missing right? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 2012-03-01 at 10:52 -0500, Paul Wouters wrote: On Thu, 1 Mar 2012, Dan Williams wrote: On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is missing right? No, it doesn't; I was hoping the DHCPv6 rule would simply be added to the default firewall config like the DHCPv4 rule is, rather than have NM open up the port every time. In an ideal world, each service requiring ports would ask the firewall itself, but the ISC DHCP client is pretty slow-moving and not too receptive of platform-specific changes like that. So if we don't get a default firewall rule for DHCPv6 then I guess NM would have to do it manually. What I was referring to was NM 0.9.4 waiting for IPv6 to time out when it already had an IPv4 address, which led to long delays in connectivity where the user's network was not IPv6 enabled, but since we want to use IPv6 if we have it, NM was waiting for it. That's fixed in 0.9.4. (0.9.3 is the development version that will become 0.9.4). Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On 03/01/2012 04:52 PM, Paul Wouters wrote: On Thu, 1 Mar 2012, Dan Williams wrote: On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is missing right? There will be a dhcpv6 service entry for firewalld soon and later on also for system-config-firewall. Where how and when it will and could be enabled will be evaluated. Paul Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, Mar 01, 2012 at 06:48:00PM +0100, Thomas Woerner wrote: On 03/01/2012 04:52 PM, Paul Wouters wrote: On Thu, 1 Mar 2012, Dan Williams wrote: On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is missing right? There will be a dhcpv6 service entry for firewalld soon and later on also for system-config-firewall. Where how and when it will and could be enabled will be evaluated. I'm going to have to chime in and say we /really/ need this in the default /etc/sysconfig/ip6tables sooner rather than later. I would hope that this could be done immediately (for F17+), rather than waiting for the related firewalld and system-config-firewall changes to be evaluated. Who does this evaluation and how do I contribute to that discussion? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Thu, 2012-03-01 at 15:43 -0500, Chuck Anderson wrote: On Thu, Mar 01, 2012 at 06:48:00PM +0100, Thomas Woerner wrote: On 03/01/2012 04:52 PM, Paul Wouters wrote: On Thu, 1 Mar 2012, Dan Williams wrote: On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: * Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. 0.9.4 snapshots do not require both methods to complete (with either success or failure) before saying the machine is connected. Thus if IPv4 completes first, NM will say it's connected, and continue IPv6 in the background. And vice versa. But that does not yet address the dhcpv6 ip6tables ACCEPT rule that is missing right? There will be a dhcpv6 service entry for firewalld soon and later on also for system-config-firewall. Where how and when it will and could be enabled will be evaluated. I'm going to have to chime in and say we /really/ need this in the default /etc/sysconfig/ip6tables sooner rather than later. I would hope that this could be done immediately (for F17+), rather than waiting for the related firewalld and system-config-firewall changes to be evaluated. Who does this evaluation and how do I contribute to that discussion? If there's a bug against this, it could be nominated as a Beta or Final blocker. It'd be a conditional breach of the 'must be able to connect to the network and install updates' criterion - the condition being 'IPv6 only network'. So that would mean we'd kick around how significant the 'IPv6 only network' case is, and whether it's yet big enough that we can consider a bug in that path a release blocker. I wouldn't want to predict the outcome of such a discussion, but it might well be worth having. Looking forward, we might at some point want to explicitly 'support' IPv6 in the release criteria, by specifying that 'connect to the network' means all permutations of IPv4 / IPv6 networks should work... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Paul Wouters Can we please address the following bug that is almsot two years old. This bug causes long delays for people enabling IPV6, and causes Fedora to not get any connectivity on IPv6 only networks, unless you disable/reconfigure ip6tables manually I find the fact that this bug is not yet fixed quite unbelievable. Ubuntu, Windows, Mac OS X, and iOS all allow DHCPv6 by default with no apparent ill effects. When you also take into account that DHCPv4 and ICMPv6 Router Advertisements (which can be used for similar auto-configuration of IPv6 network connectivity) are allowed by default in Fedora, the entire situation becomes borderline bizarre. What on earth is it about DHCPv6 specifically that causes Fedora to consider it too insecure to be allowed by default? However, this is not the only problem related to IPv6. I just tested the F17 Alpha Live CD, and one particular egregious issue is that by default, the toggle «Require IPv4 addressing for this connection to complete» is enabled in NM's connection profiles. This essentially means that IPv6-only networks are not supported out by default. If I try to connect the F17 Alpha to an IPv6-only WLAN (not making any changes to the default settings), the connection is successfully activated and remains fully functional for about 40 seconds, at which point NM gives up on waiting for replies from the non-existent DHCPv4 server. Then the entire connection is torn down, IPv6 included, before the process starts over again in a seemingly endless loop. There is no good reason for leaving the «Require IPv4» setting default enabled as far as I can tell. At least one protocol must still succeed even with both «Require IPv4» and «Require IPv6» disabled, so for the 99.5% of users that have no IPv6, IPv4 will still remain actually required, even if the setting in the connection profile is disabled. (Also, for what it's worth, Windows, Mac OS X, and iOS will all successfully connect to an IPv6-only network when using their default settings.) I have a two-year old bug report about this problem too: https://bugzilla.redhat.com/show_bug.cgi?id=538499 I have submitted patches to fix the problem: http://mail.gnome.org/archives/networkmanager-list/2011-August/msg00063.html http://mail.gnome.org/archives/networkmanager-list/2011-August/msg00062.html But still the problem remains. I don't know what else I can do to improve the situation. It is really, really frustrating. When ranting about the sad state of affairs of IPv6 support in Fedora like I do now, I like to remind people about the following statement: 4.2.2. Enhanced IPv6 support in NetworkManager For non-GUI users, and those that use ifcfg files directly, NetworkManager should bring up the interface with IPv6 connectivity correctly at boot. No modification of the ifcfg files should be necessary. For GUI users, a new IPv6 tab will appear in the connection editor which will allow for control if the IPv6 settings similar to control of IPv4 settings already. After selecting the configuration method (auto is the default, which will honor router-advertisements and attempt to retrieve DNS information with DHCPv6 information-only mode) and entering any additional settings they may wish to use, then saving the connection, activating that connection should configure the interface fully with IPv6 as requested by the user. That's from the Fedora 12 release notes. Sounds good, right? Only problem is, it was completely and utterly false. Today, more than two years and four releases later, it still is false. *sigh* It would be REALLY nice if we can get this into F17 this time. +1 The changes required to make Fedora properly support IPv6 out of the box are few and trivial. Please don't drag them out for yet another release. I'd be more than happy to help test and verify. -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Wed, Feb 29, 2012 at 4:05 AM, Tore Anderson t...@fud.no wrote: However, this is not the only problem related to IPv6. I just tested the F17 Alpha Live CD, and one particular egregious issue is that by default, the toggle «Require IPv4 addressing for this connection to complete» is enabled in NM's connection profiles. This essentially means that IPv6-only networks are not supported out by default. If I try to connect the F17 Alpha to an IPv6-only WLAN (not making any changes to the default settings), the connection is successfully activated and remains fully functional for about 40 seconds, at which point NM gives up on waiting for replies from the non-existent DHCPv4 server. Then the entire connection is torn down, IPv6 included, before the process starts over again in a seemingly endless loop. Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
* Jerry James Interesting. I'm seeing kind of the inverse problem: https://bugzilla.redhat.com/show_bug.cgi?id=771130. Could that be related to the issues discussed in this thread? Hard to tell, without (preferably debug-level) logs. I have the same problem you're describing occur in 0.9.2-1 (see bug #797524), but I've not seen it with 0.9.3-0.2.git20120215. Regards, -- Tore Anderson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DHCPv6 *still* broken for F17 alpha
On Mon, 2012-02-27 at 23:27 -0500, Paul Wouters wrote: Can we please address the following bug that is almsot two years old. This bug causes long delays for people enabling IPV6, and causes Fedora to not get any connectivity on IPv6 only networks, unless you disable/reconfigure ip6tables manually https://bugzilla.redhat.com/show_bug.cgi?id=552099 https://bugzilla.redhat.com/show_bug.cgi?id=591630 Please, just add the following rules to the default ip6tables: -A INPUT -m state --state NEW -m udp -p udp --dport 546 --sport 547 -s fe80::/10 -d fe80::/10 -j ACCEPT It would be REALLY nice if we can get this into F17 this time. At least for NM I suppose I could hack this in, but it would be really nice to get the IPv6 rules as default somewhere. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
