Hide Forgot
Description of problem: I was able to get DHCPV6 server to assign addresses using a /64 prefix but when I selected a /96 prefix then the server sent out the /96 using RADVD/DHCPV6 but the client still assigned the address using the /64 prefix instead of the /96. However, on Mac OS X 10.7 (Lion) client, it correctly set the /96 prefix. The client should set what the server sends. Version-Release number of selected component (if applicable): dhclient-4.1.1-12.P1.el6 dhcp-4.1.1-12.P1.EL6_0.4 radvd-1.6-1.el6 How reproducible: Client always seems to set a /64 prefix instead of what the server is set for. Steps to Reproduce: 1. Set Server IPV6 address for a /96 2. Set up RADVD with the server /96 prefix. 3. Set up DHCPV6 server with /96 prefix. 4. Set up client to do DHCPV6. Actual results: Client shows IPV6 with a /64. Expected results: Client should show IPV6 with a /96. Additional info:
Can you attach (the relevant part of) the configuration files for dhcpd6 and radvd. You can make them private if you want. Do you use NetworkManager, network service or you run dhclient manually ?
Created attachment 515627 [details] /etc/sysconfig/network-scripts/eth1
Created attachment 515628 [details] /etc/radvd.conf
Created attachment 515629 [details] /etc/dhcp/dhcpd6.conf
Further testing reveals the following: I think the original was a bit mis-leading. I've rebooted server and client and now the client will not even set an IP address at all. In the client /var/log/message I'm getting: dhclient: send_packet6: Cannot assign requested address dhc6: sendpacket6() sent -1 of 52 bytes. I'm now thinking that the comment #1 where it had an IPV6 address was picking that up from some previous number it had. After reboot, the client will not set any IPV6 address with this configuration. However, I also retested with MAC OS X 10.7 (Lion) and it still picks up the appropriate IPV6 address with the appropriate /96 prefix. Please let me know of there is any other info I can provide or test anything else.
I am not running NetworkManager, this is strictly using the /etc/init.d/network stop/start/restart mechanism.
All firewalls have been turned off, both on IPV4 and IPV6.
I was able to reproduce the behavior as described in description of this bug. Looking in the dhclient code I see that the prefix length is really always set to 64. There's a comment saying: /* Current practice is that all subnets are /64's, but * some suspect this may not be permanent. */ I'll try to get some answers why is it so, but from the comment it seems that this is not a bug but designed so.
Thanks for checking. I'm very glad you were able to duplicate this. I agree that many/most networks will have prefix /64 but I would argue that not all networks will have /64 prefix, otherwise there would be no need to specify /64 prefix for anything. I think it would be short-sighted to hard-code to /64 prefix.
I had looked into packets coming from server and there's nothing like prefix length specified. So I searched the RFC 3315 and it seems that DHCPv6 does not currently permit specification of a prefix length (something like subnet-mask option for DHCPv4). So I finally tried dhcp-users mailing list and found: https://lists.isc.org/pipermail/dhcp-users/2010-August/011854.html https://lists.isc.org/pipermail/dhcp-users/2010-August/011855.html Closing this as NOTABUG because according to RFC 3315 it seems that DHCPv6 was designed so.
Also this is interesting (Ted Lemon has been principal DHCP(v6) architect) https://lists.isc.org/pipermail/dhcp-users/2011-November/013912.html
The above mentioned URLs changed: https://lists.isc.org/pipermail/dhcp-users/2010-August/012226.html https://lists.isc.org/pipermail/dhcp-users/2011-November/014271.html
https://kb.isc.org/article/AA-01141/31/How-to-workaround-IPv6-prefix-length-issues-with-ISC-DHCP-clients.html
https://bugzilla.gnome.org/show_bug.cgi?id=656610