DHCPv6 *still* broken for F17 alpha

Tore Anderson tore at fud.no
Fri Mar 2 22:31:44 UTC 2012

* 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

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

More information about the devel mailing list