[Kea-users] KEA IPv6 Configuration Help?

Tomek Mrugalski tomasz at isc.org
Wed Apr 29 00:53:32 UTC 2015


On 28/04/15 16:08, Garett wrote:
> So I am fairly certain my problem is the whole "no IPv6 subnets" but that doesn't make much sense because those appeared to load just fine a few lines earlier.  I also found a vague reference to some bug that will be fixed in 0.9.2 that make unnecessary "no IPv6 subnets" messages go away so maybe it isn't that.
> 
> I know it is getting the DHCPv6 requests from the client.   I run "dhclient -6 -v enp0s3" on the virtual client and I can see the requests in the tcpdump on the server ...
> 
> [root at server ~]# tcpdump -i enp0s8 
> tcpdump: WARNING: enp0s8: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on enp0s8, link-type EN10MB (Ethernet), capture size 65535 bytes
> 16:39:16.386989 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
> 16:39:17.051220 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
> 16:39:17.331375 IP6 :: > ff02::1:ffbe:e078: ICMP6, neighbor solicitation, who has fe80::a00:27ff:febe:e078, length 24
> 16:39:18.333869 IP6 fe80::a00:27ff:febe:e078 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
> 16:39:18.335099 IP6 fe80::a00:27ff:febe:e078 > ff02::2: ICMP6, router solicitation, length 8
> 16:39:18.652743 IP6 fe80::a00:27ff:febe:e078 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
> 16:39:22.308676 IP6 fe80::a00:27ff:febe:e078 > ff02::2: ICMP6, router solicitation, length 8
> 16:39:26.311704 IP6 fe80::a00:27ff:febe:e078 > ff02::2: ICMP6, router solicitation, length 8
These are NOT DHCPv6 packets. When an IPv6 host boots up (or you enable
IPv6 interface), the first step it typically does couple things. First,
it joins all-hosts multicast group, using MLD (your packets 1,2,4,6). It
also uses ND (neighbor discovery, which is roughly IPv6 equivalent of
ARP) to discover some neighbors (packet 3). Finally, it asks whether
there are routers available on link, using Router Solicitation/Router
Advertisement mechanism (packets 5,7,8). You don't seem to have any
routers, so there are no Router Advertisements coming back.

Router Advertisement includes many informations, including router's link
address, prefixes available on link and whether they are autonomous. One
of the pieces of information in RA is M bit. It describes whether
there's a stateful (i.e. DHCPv6) service available.
Note that this bit is not normative, i.e. absence of that bit doesn't
imply that there's no DHCPv6 server. However, depending on the client's
implementation, the client may or may not be start DHCPv6 exchanges if
there is no RA received (or the M bit is not set in it).

That above is simplified explanation, but it should be sufficient to
point you to the right direction.

As for the missing DHCPv6 packet, you are looking for a packet that
is sent from client's link local address (fe80::a00:27ff:febe:e078) in
your case and it sent to the all_dhcp_relay_agents_and_servers multicast
address (that's ff02::1:2). It should be a UDP packet with source port
546 and destination port 547. Its type should be SOLICIT.
No such packet is shown in your traffic capture, i.e. this is a problem
with your client, not the server.

Hope that helps.
Tomek




More information about the Kea-users mailing list