http://bugzilla.opensuse.org/show_bug.cgi?id=933590 --- Comment #2 from Lars Müller --- (In reply to Neil Rickert from comment #1)

See also bug 916956

Thanks. This is very likely a duplicate of bug 916956 But I'd like one of our wicked maintainers to decide on this as the delay I see is a bit smaller. The Internet Access Device (IAD) I'm using is from from the vendor AVM, the model has the name Fritzbox, and model number 7390. The most current firmwawre version 06.23 is installed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=933590 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |mt@suse.com Resolution|--- |INVALID --- Comment #4 from Marius Tomaschewski --- This is not a wicked bug. For IPv6, routes are handled completely by the kernel [or statically via config], DHCPv6 is not involved here at all. When the interface goes up (e.g. "ip link set up eth0") the kernel assigns a link address to the interface (fe80::.../64), which is usually derived from the mac address. Then it verifies it for duplicates on the network and when there is no duplicate, it sends out a RS (router solicitation) asking for RA (router advertisement) for 60 seconds. When the router sends one back and the lifetime is not 0, the kernel will set a default route via this router. When the router answer periodically only [every 9 minutes], and ignores RS ... well, there will be no default route until RA arrives. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=933590 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=934067 --- Comment #7 from Marius Tomaschewski --- OK, I've opened a kernel bug for the IPv6 RA flags (managed/other-config) changes and omitted NEWLINK when AdvReachableTime==AdvRetransTimer==0 the above patch is trying to workaround: https://bugzilla.suse.com/show_bug.cgi?id=934067 See also bug 916956 comment 12 -- it is SUSEfirewall2_init which does not permit ICMPv6 (RAs, ...) -- unlike SuSEfirewall2, which is setting rules allowing it. Lars, could you test if this works properly when SUSEfirewall2* is disabled? Then we can in fact resolve this bug as duplicate of bug 916956. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=933590 http://bugzilla.opensuse.org/show_bug.cgi?id=933590#c11 Marius Tomaschewski changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |DUPLICATE Flags|needinfo?(lmuelle@suse.com) | --- Comment #11 from Marius Tomaschewski --- DHCPv6 does not deal with routes at all -- this is done in the kernel (not in wicked) using the IPv6 RA sent by the router -> blocked by SUSEfierwall2. The delayed DHCPv6 address requests issues are fixed in the kernel (patches accepted upstream) and a workaround trying to catch it is also in wicked. See also comment 7. *** This bug has been marked as a duplicate of bug 916956 *** -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=933590 http://bugzilla.opensuse.org/show_bug.cgi?id=933590#c13 --- Comment #13 from Marius Tomaschewski --- Yes, bug 934067 is the SLES-12 bug report I've opened to fix the kernel to emit NEWLINK events when "Reachable Time" and "Retrans Timer" are 0 in RA: "A value of zero means unspecified (by this router)", and "In such cases, the parameter should be ignored and the host should continue using whatever value it is already using" as stated in rfc4861 4.2/6.3.4, that is not a reason to skip anything, just nothing special provided/enforced by the router as briefly also described in comment 7. Not emitting them caused, that DHCPv6 started to request address/info late and does not has anything to do with the routes, which were set -- except, SUSEfirewall2 blocks the RA (in it's init phase). Sorry, better would be to link the info here. The kernel patches are here: http://patchwork.ozlabs.org/patch/512486/ http://patchwork.ozlabs.org/patch/512646/ and accepted upstream. Workaround to not break IPv6 RA, ... is setting: FW_BOOT_FULL_INIT="yes" in /etc/sysconfig/SuSEfirewall2. -- You are receiving this mail because: You are on the CC list for the bug.