Windows 7 and IPv6

Read­ing Time: 5 min­utes

One of the projects that I began ear­ly last year is an IPv6 roll­out across our entire world­wide net­work.  Dur­ing the ini­tial heady days of the project, I man­aged to get the infra­struc­ture large­ly con­fig­ured in a dual-stack arrange­ment.  Then some­thing came up.  I can’t remem­ber exact­ly what, at this point, but some­thing did, and so the project sat.  And sat.  And sat some more.

Ear­li­er this week, I reviewed the appalling (lack of) progress so far and began mov­ing for­ward.  I had already com­plet­ed the acqui­si­tion of Provider Inde­pen­dent Address Space (PI), get­ting our upstream providers to adver­tise the routes, and the set­ting up of 90% of the infra­struc­ture (SVI address­ing, the dif­fer­ent IPv6 set­tings like IPv6 CEF and uni­cast-rout­ing, etc.)  Every­thing here worked as expect­ed.

I decid­ed to start with the infra­struc­ture more relat­ed to the client side, includ­ing servers of inter­est (DNS, AD, mail, etc.) to the inside, and the end-user work­sta­tions.  It should be not­ed here that we had IPv6 turned off on all work­sta­tions and servers, despite Microsoft­’s best prac­tices which state that IPv6 should be left on because sev­er­al ser­vices will break with it off.  Since these ser­vices (Home­groups, for one) don’t real­ly apply in a cor­po­rate envi­ron­ment, I did­n’t care too much what their best prac­tices rec­om­mend­ed.   The first step was to turn IPv6 on for a few test machines in the IT VLAN, and a cou­ple of the Active Direc­to­ry servers.

The good news is that the servers came up and were hap­py as soon as they got their address­es.  We’re going with a scheme of sta­t­ic assign­ment for servers, infra­struc­ture man­age­ment address­es, etc., so all I real­ly had to do was click the check­box for IPv6 (these are Win­dows 2008 R2 servers), assign address and gate­way, and voila, we had reach­a­bil­i­ty.  Next, I fixed up some DNS set­tings, added some AAAA records (the IPv6 equiv­a­lent of IPv4 A records), and we had DNS res­o­lu­tion on IPv6 work­ing as well.

Win­dows 7 would­n’t prove to be quite as easy, for a few rea­sons.  While the check­box­es and set­tings are osten­si­bly the same, some of the back-end code is obvi­ous­ly dif­fer­ent and needs some non-obvi­ous tweak­ing to get right.  I could­n’t for the life of me fig­ure out why I had no reach­a­bil­i­ty, when the con­fig­u­ra­tion should actu­al­ly be easy as pie (state­less auto configuration–just “turn on” IPv6 and walk away).  In fact, I end­ed up test­ing my Mac­book Pro and a Lin­ux machine, and both of them worked as expect­ed right out of the gate, so I knew this was a Win­dows 7 prob­lem.

The first thing that occurred to me after test­ing the oth­er non-Win­dows machines was domain poli­cies.  We have a lot of them, and you nev­er know what might be caus­ing issues.  I had one of my Serv­er guys check that, and then check a non-domain Win­dows 7 machine with the same image (Win­dows 7 Enter­prise), and he came up with no applic­a­ble pol­i­cy prob­lems and the same behav­ior.

Final­ly, after spend­ing too much time with Google, I man­aged to piece togeth­er an idea of what was hap­pen­ing.  As it turns out, the mech­a­nism by which Win­dows 7 puts togeth­er its inter­face iden­ti­fiers is to blame.  I found the applic­a­ble infor­ma­tion in a post­ing from Feb­ru­ary, 2010 on a site called, linked to here .  It prob­a­bly won’t sur­prise any­one to find out that Microsoft screwed up imple­ment­ing some­thing they helped cre­ate (RFC 4941 ).  The com­mand you’ll want to run, from an ele­vat­ed com­mand prompt (or GPO, SCCM, etc.) is:

netsh interface ipv6 set global randomizeidentifiers=disabled


This takes you back to behav­ior sup­port­ed by stan­dards-com­pli­ant hard­ware, and allows your Win­dows 7 machine to actu­al­ly use IPv6.

Anoth­er com­mand you may want to use, and this is strict­ly a per­son­al and pol­i­cy choice, is:

netsh interface ipv6 set privacy disabled


This turns off pri­va­cy address­ing, an idea also described in RFC 4941.  Giv­en the glob­al­ly unique, routable nature of IPv6, I can see where some peo­ple might get squir­rel­ly, but I just don’t see the need.  Again, this is some­thing you’ll want to review for your own envi­ron­ment.

Anoth­er inter­est­ing prob­lem I found, and one more I had to solve before my Win­dows 7 machines were ready to be released back into the wild, revolves around voice.  Specif­i­cal­ly, voice VLANs.  In a voice-enabled net­work using Cis­co IP tele­pho­ny, each access port on a switch typ­i­cal­ly belongs to two VLANs: a voice VLAN and a data VLAN.  You plug a phone in, your com­put­er plugs in to a pass-through port on the phone, and each auto-mag­i­cal­ly gets an IP address in the cor­rect VLAN.  Except with IPv6.

I should say, how­ev­er, it did­n’t work that way in my envi­ron­ment.  What hap­pened here is that my work­sta­tion would actu­al­ly get an IP address in both the data and the voice VLANs.  And, due to the way pre­fix pol­i­cy works (more on that in a minute), would use the voice VLAN as the source address in traf­fic orig­i­nat­ing from the work­sta­tion.  The way I solved the prob­lem for now is to turn off IPv6 and take away the IPv6 address­ing from all of the voice VLANs (specif­i­cal­ly, on the SVIs), since I haven’t got­ten to the voice part of the IPv6 project any­way.

I don’t know what’s caus­ing the work­sta­tion to get assigned a voice address, but I’m going to con­tin­ue to look into it.  More than like­ly it has to do with State­less Auto con­fig­u­ra­tion and ND, but time will tell.  In the mean time, what’s this pre­fix pol­i­cy thing I men­tioned above?  Read about it in RFC 3484 .

Put sim­ply, IPv6 pre­fix pol­i­cy exists because any giv­en inter­face in IPv6 is going to have sev­er­al address­es; every­thing from Uni­cast to link-local, mul­ti­cast, and maybe more.  So, if I’m a work­sta­tion and I want to source traf­fic out­bound on a giv­en inter­face, which address do I use?  Pre­fix pol­i­cy helps to solve that prob­lem by “rank­ing” dif­fer­ent address­es on an inter­face in a stan­dards-spe­cif­ic way.

After read­ing the RFC, open up an ele­vat­ed com­mand prompt on your Win­dows 7 machine and enter the fol­low­ing com­mand to see how your machine is set up:

netsh int ipv6 show prefix policies


and you’ll get some­thing that looks like so:







You can manip­u­late the order of things here, and add if need­ed, using the fol­low­ing com­mands (note these are two com­mands, but word-wrap is in effect here):

netsh int ipv6 add prefixpolicy=d2a:d00c:b678:ecfb::1/128
precedence 2 label=22
netsh int ipv6 add prefixpolicy=d2a:d00c::b678::/48
precedence 2 label=22


This gives you a match­ing pre­fix pair, and says that for all traf­fic des­tined for d2a:d00c:b678::/48 net­work, use the d2a:d00c:b678:ecfb::1/128 address on the inter­face as the source.  In my case, my voice VLAN (applic­a­ble hex­tet: 107) was show­ing up in the inter­face pre­fix list before my data VLAN (applic­a­ble hex­tet: 1ff).  I could have used the exam­ple above to set the cor­rect prece­dence, but this isn’t exact­ly scal­able to thou­sands of phones and work­sta­tions, all of which may have a dif­fer­ent mix of address­es.

So, we still have the voice VLAN issue to solve, but the Win­dows 7 machines can now talk com­fort­ably on the net­work to oth­er work­sta­tions and servers, includ­ing using SSH, DNS, RDP, and all oth­er major ser­vices.  A lot of soft­ware still isn’t IPv6 com­pat­i­ble, but that’s why we’re in a dual-stack world for the fore­see­able future.

Next chal­lenge, if any­one has sug­ges­tions?  Work­ing around some of the fea­ture non-par­i­ty issues most­ly in the area of secu­ri­ty.  For instance, the ASA line as of last check still does­n’t sup­port OSPFv3 or failover via IPv6, and no tools exist that I’m aware of for map­ping com­plex secu­ri­ty pol­i­cy from IPv4 to IPv6, which is why our IPv6 world here still remains sequestered to just our net­work.

Ide­al­ly we’ll have out­side traf­fic allowed and all of our pub­lic-fac­ing ser­vices run­ning in time for World IPv6 day this year, which hap­pens on June 6th.  Mark your cal­en­dars!