Cisco have released a security advisory about multiple crafted IPv6 packets causing a reload. It seems that on a number of IOS versions with IPv6 enabled, a remote attacker can cause the router to reboot by crafting a particular series of IPv6 packets. Those of us who have been updating our IOSes recently for other reasons are in luck, as relatively recent versions of IOS appear to be safe.
This draft looks at the real (and not so real) benefits of NAT and explains how IPv6 provides for people who depend on these. The table in the introduction is a nice summary of the issues and solutions.
A couple of quick developments on the IETF front.
First is http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt - a recent draft specifying how autoconfigured nodes should do dynamic DNS updates. The most interesting thing here is that hosts can explicitly ask the router to do it for them, which should be interesting to get right; the router’ll have to keep a lot of state on large networks. But it’s another piece of the puzzle getting slotted into place.
Second is ftp://ftp.rfc-editor.org/in-notes/rfc3974.txt, an informational RFC on operating dual-stack SMTP servers. The core of the document is a description of the algorithm that should be used when dual-stack SMTP servers send mail. Since adding quad A records to MX records essentially adds an extra “dimension” to the MTA resolution process, I would recommend reading it so you get a better idea of how things work in the new world. In particular, quad A destinations are preferred over A destinations, but only within a set of MX records that have the same preferences. This means that it’s not possible to set up an experimental high-preference quad A MTA which then acts as a hoover for all of your mail, which is good, but also means it’s difficult for non-dual-stack mail servers with a low MX preference to be worked around. (One option is to put an IPv6-only server at an even-lower preference.)
Anyway, is it just me, or should we rework and reword the algorithm and the terms high- and low- preference MX, so we don’t have this running ambiguity in our heads about what we mean every time we talk about MX values?
After getting some feedback, I’ve improved my script that checks for names whose nameservers have problems responding to IPv6 queries. The script can how spot nameservers that return data, but the data is garbled. You can try out the script if you want to check your own name server. (There’s also a script that can check if your forward and reverse records match.)
I tracked down a problem last night where X forwarding doesn’t always work if ssh has to forward from an IPv6 X client to an IPv4 X server. This is with a slightly old sshd, so maybe the problem is fixed with a more recent version. I’ll post more details when I’ve checked out a newer server.
This is the place where all the errata that we have for the book will be kept.