Windows 7 and IPv6

One of the projects that I began early 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 largely con­fig­ured in a dual-stack arrange­ment.  Then some­thing came up.  I can’t remem­ber exactly what, at this point, but some­thing did, and so the project sat.  And sat.  And sat some more.

Ear­lier this week, I reviewed the appalling (lack of) progress so far and began mov­ing for­ward.  I had already com­pleted 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 unicast-routing, etc.)  Every­thing here worked as expected.

I decided to start with the infra­struc­ture more related 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 noted 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­eral ser­vices will break with it off.  Since these ser­vices (Home­groups, for one) don’t really apply in a cor­po­rate envi­ron­ment, I didn’t care too much what their best prac­tices rec­om­mended.   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­tory servers.

The good news is that the servers came up and were happy as soon as they got their addresses.  We’re going with a scheme of sta­tic assign­ment for servers, infra­struc­ture man­age­ment addresses, etc., so all I really 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­ity.  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 wouldn’t prove to be quite as easy, for a few rea­sons.  While the check­boxes and set­tings are osten­si­bly the same, some of the back-end code is obvi­ously dif­fer­ent and needs some non-obvious tweak­ing to get right.  I couldn’t for the life of me fig­ure out why I had no reach­a­bil­ity, when the con­fig­u­ra­tion should actu­ally be easy as pie (state­less auto configuration–just “turn on” IPv6 and walk away).  In fact, I ended up test­ing my Mac­book Pro and a Linux machine, and both of them worked as expected right out of the gate, so I knew this was a Win­dows 7 problem.

The first thing that occurred to me after test­ing the other non-Windows machines was domain poli­cies.  We have a lot of them, and you never know what might be caus­ing issues.  I had one of my Server 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­icy prob­lems and the same behavior.

Finally, after spend­ing too much time with Google, I man­aged to piece together an idea of what was hap­pen­ing.  As it turns out, the mech­a­nism by which Win­dows 7 puts together 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 itexpertvoice.com, 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­vated com­mand prompt (or GPO, SCCM, etc.) is:

netsh interface ipv6 set global randomizeidentifiers=disabled

 

This takes you back to behav­ior sup­ported by standards-compliant hard­ware, and allows your Win­dows 7 machine to actu­ally use IPv6.

Another com­mand you may want to use, and this is strictly a per­sonal and pol­icy choice, is:

netsh interface ipv6 set privacy disabled

 

This turns off pri­vacy address­ing, an idea also described in RFC 4941.  Given the glob­ally unique, routable nature of IPv6, I can see where some peo­ple might get squir­relly, but I just don’t see the need.  Again, this is some­thing you’ll want to review for your own environment.

Another 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­cally, voice VLANs.  In a voice-enabled net­work using Cisco IP tele­phony, each access port on a switch typ­i­cally belongs to two VLANs: a voice VLAN and a data VLAN.  You plug a phone in, your com­puter plugs in to a pass-through port on the phone, and each auto-magically gets an IP address in the cor­rect VLAN.  Except with IPv6.

I should say, how­ever, it didn’t work that way in my envi­ron­ment.  What hap­pened here is that my work­sta­tion would actu­ally get an IP address in both the data and the voice VLANs.  And, due to the way pre­fix pol­icy 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­cally, on the SVIs), since I haven’t got­ten to the voice part of the IPv6 project anyway.

I don’t know what’s caus­ing the work­sta­tion to get assigned a voice address, but I’m going to con­tinue to look into it.  More than likely 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­icy thing I men­tioned above?  Read about it in RFC 3484.

Put sim­ply, IPv6 pre­fix pol­icy exists because any given inter­face in IPv6 is going to have sev­eral addresses; 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 given inter­face, which address do I use?  Pre­fix pol­icy helps to solve that prob­lem by “rank­ing” dif­fer­ent addresses on an inter­face in a standards-specific way.

After read­ing the RFC, open up an ele­vated 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 needed, 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 exactly scal­able to thou­sands of phones and work­sta­tions, all of which may have a dif­fer­ent mix of addresses.

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 other work­sta­tions and servers, includ­ing using SSH, DNS, RDP, and all other 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-parity issues mostly in the area of secu­rity.  For instance, the ASA line as of last check still doesn’t sup­port OSPFv3 or failover via IPv6, and no tools exist that I’m aware of for map­ping com­plex secu­rity pol­icy from IPv4 to IPv6, which is why our IPv6 world here still remains sequestered to just our network.

Ide­ally we’ll have out­side traf­fic allowed and all of our public-facing ser­vices run­ning in time for World IPv6 day this year, which hap­pens on June 6th.  Mark your calendars!

Incom­ing search terms for the article:

  • Pingback: packetqueue.net » Blog Archive » IPv6 Feature Parity (Lack of) Rant()

  • Mer­rill

    I also ran into the voice vlan issue with my IPv6 deploy­ment. I opened up a TAC case, but pretty much got shuf­fled off into being ignored. I felt like the per­son I was work­ing with didn’t under­stand my issue. His solu­tion was to dis­able the voice vlan assign­ment on the ports. Since IPv6 on my VoIP side wasn’t a big deal at the time, I did the same thing you did, block the RA on the VoIP SVI.

    I found the mat­ter men­tioned in Cisco’s book IPv6 for Enter­prise Networks:

    (Pg 121)
    VLAN con­sid­er­a­tions for IPv6 are the same as for IPv4. When dual-stack con­fig­u­ra­tions
    are used, both IPv4 and IPv6 tra­verse the same VLAN. When tun­nel­ing is used, IPv4 and
    the tun­neled IPv6 (pro­to­col 41) traf­fic tra­verse the VLAN.
    IPv6 on data VLANs that are trunked along with voice VLANs (behind IP phones) is fully
    sup­ported. Depend­ing on the con­fig­u­ra­tion of the data and voice VLANs, you might
    expe­ri­ence an issue where the Layer 2 mul­ti­cast router adver­tise­ments from the Layer 3
    data VLAN inter­face might bleed over to the attached host (con­nected to the IP phone or
    a voice VLAN–enabled switch port). Basi­cally, a PC con­nected to an IP phone can
    receive RAs for both the data and voice VLANs. This is an issue that can be man­i­fest
    regard­less of ven­dor and switch/phone ver­sion. Stay tuned for updated best prac­tices on
    how to prop­erly deal with this on the Layer 3 VLAN con­fig­u­ra­tions or through a pos­si­ble
    set­ting in the Cisco IP Phones that pre­vents flood­ing of IPv6 router adver­tise­ments
    on the data VLAN.

    I still haven’t found the best prac­tice to work around this issue. It seems the mighty vlan wall isn’t so impervious.