Thursday, July 21, 2011

I was recently published in the June 2011 issue of Microsoft's Springboard Series Insider newsletter. The newsletter goes out to 1M plus IT Pros. Unfortunately it is NOT published to the web at all so I am providing the content of the article in case others are interested in reading it.

What You Should Know About IPv6
Recently in the news you might have been reading more about IPv6,
both in IT publications but even in mainstream news outlets. There have
been some significant events over the last 6 months that are worthy of a
quick mention to have an understanding of why IPv6 right now should be
of interest to you.
On February 3rd, 2011, the IANA
announced they had allocated all public IPv4 address blocks available
out to all the 5 regional registries around the globe, which are AfriNIC
(Africa), APNIC (Asia/Pacific), ARIN (North America), LACNIC (Latin
America and some Caribbean Islands) & RIPE (Europe, Middle East and
Central Asia.) These 5 regional registries allocate IPv4 and IPv6
addresses to local service providers and others who request IP address
space within their respective areas. Because each regional registry has a
different run rate of requests for IPv4 addresses, each region has a
different predicted depletion date. See the sidebar for more about the
predicted timelines. Effectively what this means is that we have emptied
out the pool of IPv4 addresses that fills the bucket of the regional
registries which then provide IP addresses to all of us.
In April, APNIC (the regional registry that handles
Asia/Pacific) ran low enough on IPv4 addresses that they can no longer
hand out larger public IPv4 address blocks and are only handing out much
smaller IPv4 address blocks per very strict guidelines. APNIC will
likely be the first regional registry to completely run out of IPv4
address blocks to hand out. RIPE,
the registry for Europe, is not much further behind and for many ISPs
and larger hosting providers it will be difficult if not almost
impossible to get larger IPv4 address blocks by the end of 2011. In
fact, the current aggressive projections is that RIPE will run out of
addressing by September of 2011.
So what impact does this have on IT Pros that run and
maintain services on the Internet today? What about services like VPN,
OWA, SharePoint, Exchange, DNS and others? Likely in the immediate short
term, not a lot. That being said, it will become more and more common
that you encounter hosts that may only have IPv6 connectivity due to the
lack of IPv4 addresses in certain parts of the world. If your services
do not have IPv6 translation services or native IPv6 available then you
will be unable to communicate with those hosts. Remember that IPv4 and
IPv6 are incompatible protocols that cannot communicate without a
protocol translator of some kind. Initially this may not be a large
concern for smaller enterprises and small business. However, for larger
international enterprises and government entities this concern is very
real. How do you handle a situation where an executive traveling in Asia
or Europe using a local ISP only has IPv6 addressing and is unable to
connect to any of the corporate resources? Do you have a plan to address
this inevitable situation?
Microsoft has enabled IPv6 by default in their recent OS
platforms and actually has a long history of working on and supporting
IPv6. Specifically Windows 7 and Windows Server 2008 R2 are IPv6 Ready
Logo certified and work well in native IPv6 environments along with
dual stack environments. (Dual stack refers to the situation where both
IPv4 and IPv6 are available on the same Layer 2 network, wired or
wireless, and the host gets both types of addresses.) Joseph Davies,
author of Understanding IPv6, Second Edition
by Microsoft Press has produced many articles on IPv6 and I highly
recommend reading them as the starting point of learning IPv6 in a
Microsoft Enterprise and Home network.
Given the difficulty of having IPv6 hosts trying to reach
IPv4 resources, clearly Microsoft would have thought of some sort of
transition services to allow IPv6 traffic on an IPv4 network and you are
correct in assuming they put those into the OS. Windows 7 and Server
2008 R2 have the following transition services built into the OS.

6to4 - tunnels IPv6 traffic over IPv4
without having to build an explicit tunnel, uses public relays to get to
the IPv6 Internet, and requires the host to have a public IPv4 address
to auto-generate it's IPv6 addresses based off that public IPv4 address.

ISATAP - allows dual stack nodes to tunnel
on top of IPv4 utilizing an ISATAP router for auto-configuration and
forwarding, doesn't require multicast, and is typically used in
enterprises to build an overlay IPv6 network on an existing IPv4 one to
get around gaps in native IPv6 routing.

Teredo - same function as 6to4 but works
behind an IPv4 NAT (able to do NAT traversal); to route to the IPv6
Internet, a Teredo relay has to be functional.

Each of the above transition services is a tool for an IT pro
to design a solution to meet their requirements for migrating and
supporting IPv6. Unfortunately, you need to understand when these
transition services are on by default and when they are not. This is
critical in Enterprise networks where compliance and auditing of
existing IPv4 traffic may be in place but a lack of understanding of
when IPv6 is or is not functional on the platform may cause additional
behavior that was not anticipated. Remember, with Windows 7 and Windows
Server 2008 R2, IPv6 is enabled by default and the OS will prefer to use
IPv6 if it is available. When IPv6 hosts are Layer 2 adjacent to each
other, hosts will auto-assign IPv6 addresses (link-local addressing) and
also auto discover and do name resolution with adjacent hosts in IPv6.
This can cause some interesting behavior for IT Operations when they are
watching reported stats back on logical Layer 3 IPv4 addresses and
suddenly the hosts begin passing all their traffic across the logical
Layer 3 IPv6 address instead! The graph for the IPv4 address goes to
almost zero and if you are not graphing the IPv6 address, you might
wonder (in an alarmed state!) where the heck all your traffic went.
Here is a quick example of IPv6 transition services being on
by default and following best practices for a deployment, but might not
result in the most desirable outcome. If you are deploying Exchange 2010
and you set up Edge Transport role servers per their recommendations in
a DMZ with Windows Server 2008 R2-based computers that are not domain
joined and happen to use public IPv4 addresses in your DMZ, you might
want to check your servers to see if they are doing 6to4 automatically.
If you did not turn off 6to4 explicitly and the server has a public IPv4
address, the server is likely sending out some traffic via it's 6to4
interface if it is getting AAAA records back via DNS which would specify
an IPv6 address as the best way to reach a host. You might see similar
behavior with Teredo if the server has a private IPv4 address.
You can check the status of your IPv6 interfaces using the following netsh commands:
netsh interface ipv6 show interfacenetsh interface ipv6 show addressnetsh interface ipv6 show route
You can turn off 6to4, ISATAP and Teredo with the following netsh commands:
netsh interface ipv6 6to4 set state state=disablednetsh interface ipv6 set teredo disablenetsh interface ipv6 isatap set state state=disabled
The takeaway is that you can't ignore IPv6. You should
proactively design and deploy solutions and transition technologies
within your environment but understand what their purpose is and if you
are running them. You will have to support IPv6 and your OS platforms
(all the major OS platforms use IPv6 first and "fallback" to IPv4) are
already making use of IPv6, so simply ignoring that the protocol is
running on your network is folly. Importantly, do NOT turn off IPv6 -
you might actually break something that is working just fine in your
network today! Additionally, if you have a separate network team that is
planning on deploying IPv6, if you turn off IPv6 you are actively
blocking the ability of that team to provide you those new services. The
key is to be aware and KNOW what you are running in your environment.
So, what are the 10 steps I should take as an IT pro to get IPv6 deployed in a Microsoft enterprise network?

A more detailed presentation can be found on my blog or on the California IPv6 Task Force website and yes, you can reach both of those sites via IPv6!
If you are able to get at least the first 3 items done, you
can participate in World IPv6 Day on June 8th, 2011. All the major
content providers on the Internet plan to make their services available
via IPv6 on that day including Facebook, Google, Yahoo!, Bing, Xbox, and
tons of others. You can find the current list at the ISOC website which also has information on how to take part in the event.
If you don't have time to get Provider Independent IPv6 space
but you would like to get something up quickly to test with on June
8th, I would recommend several tunnel broker services that you can get
up and working within minutes. If you have a router or server that can
do a 6in4 tunnel, check out IPv6 Tunnel Broker,
which is run and maintained by Hurricane Electric, a premier IPv6
provider. Additionally, if you already have a BGP ASN you can peer with
them directly via a tunnel and if you have Provider Independent IPv6
space, advertise it that way to get it working ASAP. You can also try
out the gogoCLIENT, which makes use of the Freenet6 project and has clients for Windows 7 (32 and 64-bit), Linux and OSX. Other projects like SixXS are available to do IPv6 tunnel services too.
Finally, Microsoft has ongoing articles on TechNet on all
sorts of IPv6 topics. For instance, Chris Palmer wrote a blog entry on World IPv6 Day and Windows and Microsoft keeps an ongoing IPv6 Blog along with its main IPv6 site at www.microsoft.com/ipv6,
which contains links and resources about IPv6. To top it all off, there
are regional task forces across the world that are helping to spread
the word locally about IPv6. You can find out more about them on the IPv6 Forum. Finally, make sure to check out Bing on June 8th via your IPv6 connection!

Ed Horley
is a Principal Solutions Architect at Groupware Technology in the San
Francisco Bay Area. Ed is actively involved in IPv6 serving as the
co-chair of the California IPv6 Task Force and additionally helping with the North American IPv6 Task Force.
He is a current Microsoft MVP (first awarded back in 2004) and has
spent the last 15 years working in networking as an IT professional. He
is actively involved in the Pacific IT Professionals users group and enjoys umpiring women's lacrosse when he isn't playing around on IPv6 networks. Contact him at ed@howfunky.com or check out his blog at www.howfunky.com. - Ed