On Mon, 2012-02-27 at 23:27 -0500, Paul Wouters wrote: 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

On Wed, Feb 29, 2012 at 4:05 AM, Tore Anderson <tore(a)fud.no&gt; wrote: 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/

On Wed, 2012-02-29 at 17:20 +0100, Tore Anderson wrote: 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

On Thu, 2012-03-01 at 10:52 -0500, Paul Wouters wrote: 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

On Thu, Mar 01, 2012 at 06:48:00PM +0100, Thomas Woerner wrote: 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?

On Thu, 2012-03-01 at 15:43 -0500, Chuck Anderson wrote: 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

Hi, * Adam Williamson 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. +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. Yes please. Besides, you promised as much in the F12 release notes... Regards, -- Tore Anderson

* Tom Callaway 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

On Fri, 2012-03-02 at 15:22 +0100, Tore Anderson wrote: 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

* Adam Williamson I meant «you» as in «The Fedora Project». ;-) -- Tore Anderson

* Tom Callaway 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

On Fri, 2012-03-02 at 14:52 +0100, Tore Anderson wrote: 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

On 03/02/2012 11:31 PM, Tore Anderson wrote: 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

On Wed, 2012-03-14 at 20:47 +0100, Lars Seipel wrote: 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

On Thu, 15 Mar 2012, Dan Williams wrote: 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

Hi Dan, * Dan Williams 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! 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 internet. On the other hand, ULAs might also be used in parallel to public addresses handed out by ISPs. This scenario is described in RFC 6204. The idea is that while the global addresses from the ISP may change from time to time, just like your global IPv4 address does, the ULAs will remain stable. That allows your manually-configured network printer to keep working after you change ISPs, for example. So if you want to look at ULAs to determine if the connectivity is site-local or not, you'll also have to ascertain whether or not there's any other global addresses present. Some sort of a connectivity check might in any case be useful, though. MS Windows does this, only passively. It doesn't say you're connected to the internet before you actually got some traffic from there (e.g. by visiting a web site). Best regards, -- Tore Anderson

On 2012-03-15 Dan Williams wrote: connection, 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.

Le Lun 19 mars 2012 10:17, Nicolas Mailhot a écrit : Forgot this: https://bugzilla.mozilla.org/show_bug.cgi?id=728658 -- Nicolas Mailhot