Thank you. FWIW, our config is virtually the same for our DHCPv4 service (except we use "match hardware," as mentioned in my original message), and class matching works as expected. (I tested it after encountering the v6 problems to make sure I understood what I was doing.) > On Jun 28, 2017, at 3:47 AM, Thomas Markwalder via RT wrote: > > Hello Rob: > > We have pulled the files down, thank you. The full config file is quite large which may have something to do with it. My testing here was done based on the snippet you included before. > > I will keep you updated with our findings but it may be a bit before we can spend much time on it. > > Regards, > > Thomas Markwalder > ISC Software Engineering > > On Tue Jun 27 23:40:44 2017, riepel@stanford.edu wrote: >> On Jun 27, 2017, at 10:41 AM, Thomas Markwalder via RT > confidential@isc.org> wrote: >> >> >>> This is an intriguing problem. Thus far, using your configuration we >>> have not been able to produce a mismatch. We are winding up work on >>> our next releases, 4.3.6/4.1-ESV-R15, which are due out 7/31/17, so >>> our resources are somewhat limited. >>> >>> Could you supply us with pcaps of the traffic that causes the >>> mismatch? >> >> As you can see from the files, I restart the server, started tcpdump >> (dst port 547 or dst port 546), and then told the "vile" client (same >> one as before) to configure IPv6 automatically. It matched "roaming" >> right off. The subsequent client, ac:bc:32:d3:2a:f1, which is a valid >> "roaming" client didn't explicitly match "roaming," but it didn't get >> an address either. About 15 seconds later it matched "roaming" and got >> an address. >> >> I've put the full config, log, and pcap files up at >> http://web.stanford.edu/~riepel/dhcpv6/ >> >> Let me know when you've got them so I remove them. Thanks. >> >> -- >> Rob Riepel