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 UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 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 expected). 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 interface. Linux hcf 2.6.16.27-hcf-0.9-default #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? https://secure.isc.org/store/t-shirt/ -- 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:
pgpqyjv9wL06Y.pgp
Description: PGP signature