DHCPv6 *still* broken for F17 alpha

[Thomas Woerner]

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'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,
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