DHCPv6 *still* broken for F17 alpha

[Tore Anderson]

* 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