It's been awhile since I've written anything here, so this will be a somewhat combined post.

For three days last week I attended an IPv6 training course at the Microsoft campus in Charlotte.  The course was primarily for systems engineers from my department, but I sat in with the hopes that I might pick up a thing or two that will help keep our teams on the same page regarding IPv6 deployment.

The course went over IPv6 basics, transition technologies, deployment considerations, and touched a little bit on security.  There were a few labs, which involved setting up various IPv6-related scenarios on Windows Server 2008 R2 (via Hyper-V on laptops, shocker there).

The content of the course was fairly decent, except for three major errors that I pointed out during the instruction:

(1) It was initially stated that clients send one DNS request to their local cache.  The cache decides if it should return an A or AAAA record, based on some fictious variables.  This was corrected (DNS clients send both A and AAAA queries to the cache, then themselves determine which should be used based on the presence of a GUA address and default route).

(2) When discussing 6to4 tunneling, it was stated that local relays should be used, with no mention of 192.88.99.1.  Oddly, the course material stated that 6to4.ipv6.microsoft.com should be used as the relay, which has an A record of 192.88.99.1.

(3) It was stated that router-to-router links must use /64s.  I cited that many major ISPs in the United States currently use /126s and /127s for such links, backing it up with some text from RFC 6164 (section 5, specifically).

The course also introduced some strong recommendations I vehemently disagreed with, one of which is the use of RAs and DHCPv6 in the enterprise data center.  The instructor stated over and over again that it's hard to type in IPv6 addresses compared to IPv4 addresses for every single server, when using static assignments.  So, of course, the solution is the use of RAs (with the M and O flags set), DHCPv6, and DDNS.

I think this is a horrible idea because of the added complexity and dependence on not one, or two, but three external services: router advertisements, DHCPv6 services, and dynamic DNS.  The failure of any of these can possibly lead to servers becoming unreachable after a reboot or other network-related interruption.  To get even more basic, I object to the use of router advertisements (RAs) in the enterprise data center, to begin with.  Sure, in greenfield deployments this might be fine, but turning up RAs cause all IPv6-aware hosts to add a default route, if nothing else (assume the A flag is disabled).  This is all some operating systems need to cause the network stacks to start resolving AAAA records and attempt to connect to IPv6 addresses before they're really ready.  So, then, in order to selectively turn up IPv6 on some servers, all the other servers must be configured to not accept RAs - a monumental task for most enterprises where there are many platforms involved.

It was also mentioned that the DHCPv6 server on Windows Server 2008 R2 doesn't support static reservations for clients, so there's no way to ensure that clients receive the same address each time, other than the almost infinitely large address space in a /64.  For this reason, it appears that it might not be possible to definitively predetermine the IPv6 address of a server before it hits the wire in the data center.  To add some icing on the cake, it was suggested that firewall policies be based on the DNS, not addresses or prefixes!

Really, is manually typing an IPv6 and IPv4 address really that difficult to do during the server provisioning process?  It only needs to be done once, and can easily be scripted.  I asked the instructor for the reasoning behind this DHCPv6 recommendation, and got nothing more than "typing IPv6 addresses is hard."  Flummoxed, I started up a thread on the IPv6 operations mailing list, bug got back less than definitive results.

Anyway, the course was fairly well-received by the systems engineers, and I think it'll help speed up deployment in our data centers (erm, it's been there for awhile, but no RAs!).  However, I have a feeling I'll be fighting folks on the DHCPv6 issue in the future, if Microsoft sticks with their current recommendation.  I got to pass by the Microsoft company store as part of the trip, and picked up some software on the cheap and a Microsoft shirt I'll be sure to wear to the office (to confuse everyone, obviously).

In unrelated news, there's a bill floating around in the House of Representatives that could possibly do some decent damage to the Internet in the United States: SOPA.  The Stop Online Piracy Act (SOPA, H.R. 3261) is a bill introduced in the House with the goal to fight copyright infringement and counterfeitting on the Internet.  Unfortunately, this bill is so broad that it threatens some open source projects and opens the door for federally-mandated DNS filtering (ie, censorship), something that should send shivers down your spine.  Read more about it at the EFF.  Feel free to call or write to your congressmen and state representatives about it.  Really, this bill needs to be done away with.

Oh, I finally got a real SSL certificate for *.prolixium.com from GoDaddy, recently.  If you hit the SSL version of my site, you shouldn't get any certificate errors.  I also transferred prolixium.com and prolixium.net from Register.com to GoDaddy, too.  It was fairly painless, but took a week for Register.com to get me the EPP codes and authorize the transfer.  Other than Register.com's prices being highway robbery, I transferred because of this response to my question about DNSSEC support:

Discussion Thread
---------------------------------------------------------------
Response Via Email(David B.) - 11/03/2011 01:14 PM
Dear Mark.

Thank you for contacting Register.com.

We currently do not support the DNSSEC provision in the registry and at this time there is no indication that this will be added for our customers.

If you have any further questions, please reply to this email or contact a Web Services Consultant 24 hours a day, 7 days a week, at the numbers below.

Thank you for choosing Register.com.

Customer Support
Register.com, Inc.
Toll free within the U.S. and Canada: (877) 731-4441
Outside the U.S. and Canada: (902) 749-5918

Well, now that I'm with GoDaddy for almost all of my domains, and they support DNSSEC now, I should probably set it up, right?  Yeah, I'll get to it later!

New comments are currently disabled for this entry.