strange problem with ipv6 site-local dummy

From: David W. Hankins
Date: Tue Mar 11 2008 - 10:03:32 EST

This is maybe entirely academic; I was only testing some DHCPv6
software over a dummy interface, and maybe found an odd IPv6 bug,
but as it only probably makes creating a test case problematic, it
may not matter generally;

dummy0 Link encap:Ethernet HWaddr 8A:A8:E0:20:41:C7
inet6 addr: fe80::88a8:e0ff:fe20:41c7/64 Scope:Link
inet6 addr: 2001:4f8:0:ffff::f/64 Scope:Global
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:5300 (5.1 Kb)

First, I can ping6 both those addresses (with the -I option, as

A DHCPv6 server and client are using common code (the same library)
to transmit (and receive) normal UDP sockets bound to the v6
inaddr-any on the respective server and client port numbers. No
craziness with raw sockets like we do in IPv4. The software (on
both sides) just checks the cmsg to match received packets to
interfaces it has been configured to work on (in this case, just the
one dummy0).

Code snippet:

m.msg_control = &control_buf;
m.msg_controllen = sizeof(control_buf);
cmsg = CMSG_FIRSTHDR(&m);
cmsg->cmsg_level = IPPROTO_IPV6;
cmsg->cmsg_type = IPV6_PKTINFO;
cmsg->cmsg_len = CMSG_LEN(sizeof(*pktinfo));
pktinfo = (struct in6_pktinfo *)CMSG_DATA(cmsg);
memset(pktinfo, 0, sizeof(*pktinfo));
pktinfo->ipi6_ifindex = if_nametoindex(interface->name);
m.msg_controllen = cmsg->cmsg_len;

result = sendmsg(interface->wfdesc, &m, 0);

And we check result for errors, and do log messages. There are none.

Debug shows interface->name to be 'dummy0' and the resulting index to
be 5. This is the same on the client and server.

The difference of course is that the client is transmitting to a
site-local multicast address ("all dhcpv6 servers and relays"),
and the server is replying to that packet's IPv6 source address (which
is according to both tcpdump and the DHCPv6 server, correctly, the
dummy0 link-local address):

Picking pool address 2001:4f8:0:ffff:f0fd:994d:b59c:539f
Sending Advertise to fe80::88a8:e0ff:fe20:41c7 port 546

However the Advertise never appears in tcpdump, nor is it ever
received by the client. To be clear: We can receive the client's
packets, but the client never receives the server's answers.

So, this is pretty weird. I can ping6 the dummy interface's site
local address, but the ICMPv6 packets never show up in tcpdump. I can
send to a link local multicast on the dummy, and get it tcpdumped and
also see the reply out the udp socket on the other side. I cannot
seem to send to the configured link local on the dummy itself at all;
it neither shows up in tcpdump, nor does it appear in my udp socket's
receive buffer (never wakes up from select except to timeout).

Note that all this software works over a real network, so long as the
client and server are on different boxes. But it is hard to have
'make test' ask the operator to run the same thing on a different
box. :(

I suspect, but have not verified, that we would have the same problem
running the services on a physical interface. It seems to be the
case, but I have not looked a second time with a peer looking over my
shoulder to make sure I wasn't just confused.

If you wish to reproduce, you can download ISC DHCP 4.x from isc's
website, and (if you are brave or foolish) configure a DHCP server
very simply on a dummy0 interface;

ddns-update-style none;

subnet6 blah::/64 {
range6 blah:blah::/72;

Substituting for a correct global v6 subnet ifconfig'd on the

Linux hcf #1 Fri Mar 16 09:33:46 CET 2007 i686 i686 i386 GNU/Linux

The system is SuSe 10.1, with very minimal kernel patches to keep it
alive through suspend-to-ram on a Dell D610 laptop.

Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins

Attachment: pgp00000.pgp
Description: PGP signature