Part and parcel of learning about IPv6 has been establishing an internal infrastructure capable of running it, and which must be readily reconfigurable in order to test common configurations. Stephen H and I have spent dozens of hours trying various configurations of modern, common, small-network configurations as part of the research v6 testbed.
In no particular order, here are some things we’ve learned:
China – For years we used to say to people who claimed to be interested in network security, “Listen, most Internet-based attacks are coming from address blocks allocated to China, and tracerouting would seem to indicate that there are thousands and thousands and millions of break-in attempts every day.” And…they’d look at me as though I’d shown them a mouthful of black beetles whilst wearing an aluminum-lined baseball helmet, so eventually I just quit talking about it.
Mind you, this started in the early 1990s. As I’ve been watching network traffic, I noticed it’s only gotten worse, so I’ve blocked basically all APNIC and Russian address blocks, which has significantly cut down on the random attack traffic I’ve seen.
Why should we care? Because one big feature of v6 is that it [potentially] brings back the end-to-end architecture that is TCP/IP’s original primary design feature. You won’t need NAT and everything will be hunky-dory, and or peachy keen, whatever those mean. Unfortunately, one good side effect of NAT is security-through-inaccessibility, as in you can’t attack what you can’t get to. With e-to-e v6, though, your hosts are potentially once again available for attack. Because c6 hasn’t been widely tested (by crackers), it’s a good bet that many implementations will have a lot of security problems in their first few years of deployment.
Windows IP Helper Service – IPv6 transitional assistance service (“Provides tunnel connectivity using IPv6 transition technologies (6to4, ISATAP, Port Proxy, and Teredo), and IP-HTTPS. If this service is stopped, the computer will not have the enhanced connectivity benefits that these technologies offer.”) While debugging some other network issues, I discovered that at least on one machine, having this service running was generating a lot of network activity to weird random IP addresses on the Internet. It’s off for the moment until I can confirm that this is normal behavior.
DNS – Domain controllers with multiple NICs that are running DNS will not necessarily return the expected IP address. The default setting is to round-robin-return the various NIC addresses that register themselves with DNS. Our first thought was, “turn off round robin,” but that didn’t work, and then “don’t allow DNS registration,” and that didn’t work.
Current status: not solved
Current “solution”: from Microsoft-> don’t run DCs with multiple NICs. Seriously, this is their advice.