Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 196429 - DHCPv6 server in rawhide returns malformed replies
DHCPv6 server in rawhide returns malformed replies
Product: Fedora
Classification: Fedora
Component: dhcpv6 (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: David Cantrell
Depends On:
Blocks: FC6Target
  Show dependency treegraph
Reported: 2006-06-23 04:43 EDT by Tomas Mraz
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-22 12:40:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Mraz 2006-06-23 04:43:03 EDT
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
Jun 23 09:56:48 ipv6srot dhcp6c[6736]: failed to parse options
Jun 23 09:56:48 ipv6srot dhcp6c[6736]: unexpected reply
Comment 1 Jason Vas Dias 2006-07-19 02:58:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.