Problem description: a MS Windows (7,8,8.1,10) client doesn't get an IPv6 address when it connects to the network
The client must send a DHCPv6 request with a DUID that contains the MAC address of the requesting interface. The MAC address must be registered in LANDB (Network database) in order to be allowed to get an address.
Possible workrounds:
Problem description: using DHCPv6 on SLC5 at CERN requires some tweaking of the network configuration files, due to a RedHat bug (https://bugzilla.redhat.com/show_bug.cgi?id=591630, https://bugzilla.redhat.com/show_bug.cgi?id=634857) and the way devices are authorized to connect to the network at CERN (i.e. by MAC address identification).
This page is obsolete and may no longer be relevant with the latest version of SLC6.
Problem description: client may not get a DHCPv6 lease for an interface even if the MAC address of the used interface is correcty registered in landb.
Solution: several clients (MacOS X, Windows, Linux) may use the MAC of any of its interfaces in the DHCPv6 request, regardless of the interface used to send it. The workaround is to register in landb all the MAC addresses in use by the client.
Problem description: an Ubuntu client doesn't configure the IPv6 address at boot time. But running manually "dhclient -6" works. dmesg reports:
[ 11.997321] type=1400 audit(1372427393.005:35): apparmor="DENIED" operation="open" parent=1053 profile="/sbin/dhclient" name="/var/lib/NetworkManager/dhclient6-eth0.conf" pid=1765 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Problem description: a Linux client doesn't get the IPv6 client when it connects to the network
The client must send a DHCPv6 request with a DUID that contains the MAC address of the requesting interface. The MAC address must be registered in LANDB (Network database) in order to be allowed to get an address.
Possible workrounds: