Server from dhcpv6-0.10-26 returns malformed replies to dhcpv6 client. The client version is dhcpv6_client-0.10-16.1. When the server is downgraded to the same version as client, it works fine. The syslog on client machine contains: Jun 23 09:56:48 ipv6srot dhcp6c[6736]: malformed IA option: type 16384, len 33 28 Jun 23 09:56:48 ipv6srot dhcp6c[6736]: failed to parse options Jun 23 09:56:48 ipv6srot dhcp6c[6736]: unexpected reply
This is now fixed with dhcpv6-0.10-30 in rawhide / FC-6 . The problem was that previous to dhcpv6-0.10-24? the only way to set the client address prefix was by router advertisement; after adding the new address, dhcpv6 expected the route dst_len to be set automatically by router advertisement in the kernel ; this did not happen, (unless a radvd was running on the network) so effectively, no client address prefixes could be set without radvd. Then, with -24, I made the server explicitly send the prefix length configured in the server configuration file to the client; but this broke the packet parse for earlier clients. Now, clients must send a new 'DH6OPT_REQUEST_PREFIX' nil-valued option (28), which will cause the server to send the extra prefix length byte, if the 'address{ .. prefix ...}' option or 'range ::x ::x/NN' statements specify a non-zero prefix. This can be disabled in dhcp6c.conf and dhcp6s.conf by use of the new 'use_ra_prefix' option, which specifies the default upstream behaviour of relying on radvd for the address prefixes.