IPv6 Link-local Multicast Name Resolution (LLMNR) in Windows 7

While I was working on some IPv6 testing I noticed some interesting udp listener ports on my system and I couldn't remember what the port was actually used for. In this case I did the following:

C:\Users\Ed>netstat -p UDPv6 -an

Active Connections

  Proto  Local Address          Foreign Address        State
  UDP    [::]:5355              *:*
<removed for brevity>

UDP port 5355 is part of the Link-local Multicast Name Resolution (LLMNR) process and technically in IPv6 is actually a multicast process listening on the multicast address FF02::1:3

What is the the purpose of LLMNR? LLMNR allows hosts on the same subnet to be able to resolve hostnames without the need for a DNS server. It is based on DNS and the best write up is still by Joseph Davies for his Cable Guy articles.

It is more useful for home network situations or where teams are building out temporary wireless or wired networks to collaborate. Unfortunately, LLMNR isn't utilized by Linux or OSX at all. Apple came up with mDNS and later DNS-SD to address the name resolution issues for local networking and it appears that some Linux implementations utilize that also. There is a nice write up of some of the Zero Configuration Networking options on Wikipedia.
- Ed

Network World article - How to get IPv6 address space from ARIN

My article for Network World on How to get IPv6 address space from ARIN was published last month and I forgot to post anything about it. As with my previous Network World article it requires registration on their site but I hope you can live through that to take the time to read it. I might later be able to repost the full article on my blog but for now the only access is via Network World.
- Ed

When to consider using Provider Assigned IPv6 address space

For network engineers who spend their days designing IP network and running BGP the thought of running Provider Assigned (PA) IPv6 address space is often meet with a look of repulsion and disdain. Given the relative easy for most enterprise network engineers to run multi-homed BGP and to have redundant Internet Service Providers with a single IPv4 or IPv6 address block this might be a justified reaction. However, there are cases for smaller businesses and even smaller branch offices to run IPv6 PA address space that might make sense.

For instance, if you have a remote office that has limited service provider options and perhaps it is not cost effective to run BGP at the remote site you can utilize PA space to dual stack the site and simply put IPv6 ACL's in place to building corporate access policies. For small businesses it makes little sense to try and BGP multi-home due to the hardware and engineering talent required to maintain such arrangements. Considering how infrequent it is for a company to change ISP's for a given location it is not inconceivable that turning up a new service provider and migrating to a new PA block is a reasonable solution for many.

The biggest outcry I hear most often is from System Administrators who seem to think changing IP addresses will break all their server configurations, printer settings and other items. My calm reply is that they can continue to utilize IPv4 RFC 1918 space as they were and that if they are not using DNS for name resolution by now then they should likely not have that SA job anymore. DNS allows for an easy migration from one PA block to a new one with minimal impact. In addition, you can utilize DHCPv6 to manage resources and the lease times ensuring that the migration can be quick and relatively painless like most other maintenance windows for OS upgrades or WAN service provider transitions. In addition, hosts are designed to have multiple IPv6 addresses in use at the same time which theoretically means the host would control the timing of the cut-over from one PA space to a new one.

To top it off, it could be argued that for MPLS or other WAN services it might make sense to get PA space for those point to point links and allow for better summary aggregate routing for the Provider Independent (PI)  space you do have as /48 sites without wasting a /48 for WAN or VPN links within your network. You could even put route filtering in place to prevent the propagation of the PA space out of your network which would control transit WAN/MPLS traffic loads. Just because the Global Unicast Address (GUA) space you get from your provider is available to route globally doesn't mean you have to advertise it or even have the service provider advertise it either.

With the recent introduction of RFC 6296 it is possible to migrate from one prefix to the other in one move but to do this requires some downtime while the prefix replacement happens. It also introduces the problem of what IPv6 address does the host actually have at any given moment (it won't have both like a migration.) Realistically it breaks the end to end transport by being yet another version of NAT. While it is a good tool to have I don't advocate utilizing it unless the use case truly dictates needing it. Just migrate to a new IPv6 address block and things will work as expected. Hopefully your business will grow enough that the migration will be to PI address space and you only have to do the migration once!
- Ed

Odd IPv6 ULA use cases

I have to be honest, I am not a huge fan of the idea of IPv6 ULA (unique local addressing) at all. I have seen several use cases presented and even some knowledge based articles written saying to use it such as this one by Apple. There are ULA address prefix generators like this one at SixXS which are useful if you want to do ULA, my question is WHY?

At the core of the question is what do you gain by doing ULA that you don't get with doing Global Unicast Addressing? I would argue you get no benefit of having to global register a /48 ULA then simply applying for a /48 or larger from ARIN or one of the other regional registries that provide public IPv6 address space with the exception of price (which could be a big deal for some small businesses but just get your IPv6 address space from your provider for free then.) Furthermore, ULA by definition in rfc4193 cannot be routed globally and must be filtered at the edge which very much limits your IPv6 deployment and ensures you have to either deploy Global Unicast Addressing at a later date or do prefix translation as described in rfc6296 which is a viable solution but seems to introduce yet another network translation component on the network when one is not needed if you simply used Global Unicast Addressing the first time around.

The other concern I have is some OS platforms not behaving as expected when getting ULA addresses. Ideally all OS behavior with ULA would know that you don't have global IPv6 access with a ULA at all but if you are using prefix translation is that still true? Also, since IPv6 is preferred do we run into a case where the network team is putting ULA in play and breaking some of the default OS behavior that is desired for transitioning to IPv6?

Given the fact that the effort is almost identical for deploying ULA and it is Global Unicast I am not convinced that ULA is something that is needed or should be recommended. I would love to hear feedback on this one. The few corner use cases I have heard still do not seem to overcome the argument of just using Global Unicast.
- Ed

gogoNETLive! 2 IPv6 Conference wrap up

If you missed the gogoNETLive! 2 IPv6 Conference that happened at San Jose State University last week you can still get a chance to see the content from the conference. Almost all the sessions were recorded and the video and pdf's of the slides will be posted soon. I encourage you to check out last years content also, the majority of that is still applicable and a valuable baseline for understanding what is happening in IPv6.

The next big IPv6 events happening will be the IPv6 World Congress in Paris, France and then the re branded Rocky Mountain IPv6 Summit which is now being called the 2012 North American IPv6 Summit. The North American IPv6 Summit is by far the largest IPv6 event in the US and is expected to have over 500 folks attending and will likely sell out. If you have any interest at all in getting good practical IPv6 knowledge from real world experts both these events would be worth your time and effort.
- Ed

Network World article - Who's who in IPv6

My article for Network World on Who's who in IPv6 was published a few days ago. It requires registration on their site but I hope you live through that to take a read. I might later be able to repost the full article on my blog but for now the only access is via Network World.

I am very much interested in feedback of who you felt I left off the list. I have some caveats, I was not able to do a who's who for service provider manufactures, professional services consulting, training/education, OS's/applications and security solutions. There just wasn't enough room. Perhaps I will get the chance to do that in another article.
- Ed

CAv6TF and gogoNETLive!2 IPv6 Conference - Nov 1-3

Nov 1-3 the gogoNETLive!2 IPv6 Conference will be happening at San Jose State University. The line up of speakers is excellent and there will be a day of hands on practical labs to learn IPv6. To get in on the labs you should sign up right away, it is first come first served. To register for the event visit the registration page. You can hit me up on twitter (@ehorley) to get a discount code.

This event is the only dedicated IPv6 focused conference that happens in California and the CAv6TF is hoping that folks take advantage of the opportunity to learn about IPv6.
- Ed

Microsoft Private Cloud

Every hardware and software manufacture has a different definition and thoughts around cloud, both public and private. Few are big enough to have impact on the industry in any meaningful way. Some who do that come to mind are Cisco, Amazon, Apple, VMware, Citrix and Microsoft.

On Tuesday evening (Oct 4th) at the monthly PacITPros event in San Francisco Chris Henley (@chrisjhenley) with Microsoft will be presenting on Microsoft's approach to private cloud. If you are interested at all in what Microsoft is doing, what direction and strategy they are utilizing and how it will impact you then this is a presentation not to miss. Chris is a great speaker and is honest and open about what he can share. The great thing about Chris is that he and his teammates (IT Pro Evangelist in the Developer Platform Evangelist group) all do practical hands on projects and labs with the OS and help in developing solutions that make sense for IT Pros.

So if you haven't RSVP'ed for the monthly San Francisco meeting go do it now, you get free pizza and a chance to hear first hand how Microsoft will be approaching private cloud, what more could you ask for?
- Ed

Some IPv6 humor

Ethan Banks (@ecbanks) tweeted this out and I thought it was amusing and wanted to keep a link to it so here it is for your amusement:

It hits home about some of the challenges around discussing IPv6.
- Ed

PacITPros LA IPv6 Presentation Follow Up, Cisco ACE supporting IPv6 and gogoNETLive!2 IPv6 Conference

Thank you to all who showed up to see me present at the Los Angeles Pacific IT Professionals User Group meeting on Tuesday. The crowd was wonderful and asked some great questions about IPv6.

We ended up changing the topic a bit at the last minute for the meeting to better tailor the content to those who were signed up to attend. As a result, the presentation was titled "The What, Why and When of IPv6 - should I even care?" and the presentation was focused on the basics of IPv6, what is it, why should I care about it and when it affect you or your clients. It covered some basic background about the IPv6 protocol, what products and technologies are utilizing it today and how that impacts what you do as an IT Professional. The presentation is available to download from the user group's MeetUp site - just register and you can download it. Lots of thanks to Microsoft MVP Jessica DeVita who hosts and runs the meetings, she did a wonderful job as always and to Microsoft MVP Richard Hicks who presented on DirectAccess immediately after me.

Also, Cisco made up some IPv6 ground in their ACE platform with their new code release announcement on the Sept 20th. As of ACE A5(1.0) which added some much needed IPv6 features. Shannon McFarland has a great write up on his blog so I won't bother repeating it. I do now have to modify my support statements about ACE and IPv6 so for those Cisco SE's who have seen my presentations in the past please read the release notes and Shannon's blog - it will clear up a lot of items.

To round things out, the gogoNETLive!2 IPv6 conference is open for registration now. The conference is Nov 1-3rd and if you sign up prior to Oct 1st and use the discount code "earlybird" you can get 25% off. If you are a student simply use the code "student" and you will get 75% off - you need a valid student ID to show at the time of the conference or you will be charged the full price. The line up of presenters is great and they will be adding more! This conference will be worth both your time and money to attend.
- Ed

Presenting in Los Angeles on Deploying IPv6 in Microsoft Enterprise Networks

On Tuesday, September 20th at 6pm I will be in downtown Los Angeles at the Pacific IT Professionals User Group meeting presenting on Deploying IPv6 in a Microsoft Enterprise Network. In addition, Richard Hicks (fellow MVP) will be presenting on DirectAccess. I'm excited that Jessica DeVita (another MVP!) who runs the group invited me to come and present. If you are in Los Angeles and want to come join us the event is free to attend and you can sign up at their MeetUp site.

I will post the presentation after the event, I'm still updating some of the content. A quick abstract for my presentation.

Abstract: The presentation is focused on the basic deployment items that system and network administrators need to pay attention to for Enterprises networks that are primarily Microsoft focused. Topics covered include default IPv6 behavior of different Windows OS's, when transition technologies are enabled, what Microsoft products will use IPv6 and deployment guide modifications for Exchange, DirectAccess, Forefront UAG and TMG. In addition, if time allows, some design challenges around DHCP and DNS and how Windows 7 will behave vs Apple OSX or Linux implementations.

Hope to see you there!
- Ed Horley - Microsoft MVP - Windows IT Pro

ARIN IPv6 end user address allocations

I recently attended one of the ARIN Road show events and one of the topics of discussion was the recent change in IPv6 allocation justification. I wanted to review through the new policy guidelines and give more of a quick overview guide and thoughts to what they are doing in their approach to IPv6 address allocations.

The quick and dirty for those that have an existing ASN and are multi-homed is that you automatically qualify for a /48 delegation from ARIN which is considered a single "site." Translating that into number of subnets you have to build out as /64 networks is 64-48=16 which would be 2^16 or 65,536.

Not bad but there are a lot of use cases where that will not be enough depending on what your organization is providing in terms of services. To reduce the amount of work that ARIN has to do in terms of justification they have made some very simple breakdowns based on the number of sites an organization has or will have within the next 12 months. An initial size allocation will be based off the largest site you operate and the following:
- More than 1 but less than or equal to 12 sites justified, receives a /44 assignment
- More than 12 but less than or equal to 192 sites justified, receives a /40 assignment
- More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment
- More than 3,072 but less than or equal to 49,152 sites justified, receives a /32 assignment

If you have more than 49,152 sites you should look at the ISP Address Space Guidelines, that will cover the allocation requirements for much larger organizations.

As you can tell, it is pretty simple, you take the largest site you have and use that as the allocation basis. More than likely it fits within the /48 definitions. If so, then the allocation rules above (which allocate on natural nibble boundaries) are very generous. Keep in mind, the largest site you have dictates the use case so the reality is even if you have a smaller remote office with 12 folks they will get a /48 in this design. It allows you to grow that site to be identical to your largest current site topology.

The /40 allocation is really large, if you are at 16 sites for example you end up with 256 sites (because of the round up to the next nibble boundary) with /48 address blocks each with 65,536 /64 subnets. That /40 is 16,777,216 /64 subnets for a single organization to operate and use. If your organization today is making use of RFC 1918 IPv4 address space this allocation is identical in terms of the number of subnets in IPv6 verses the total number of IPv4 addresses in RFC 1918 10.0.0.0/8. You get as many subnets in a /40 delegation from ARIN as the total number of addresses you are used to using in RFC 1918 10.0.0.0/8 IPv4, that is an insane amount of address space!

By moving on a natural nibble boundary ARIN is being incredibly generous with IPv6 addresses but they are also simplifying the routing table by summarizing on easy subnet boundaries. They are gambling that the routing table summarization will pay off long term with service providers supporting end user delegations. This assumes that end users are not going crazy breaking up their subnet advertisements from their early initial allocations or at least do them on even nibble boundaries.

So, from the example above you can see that ARIN is doing the opposite of the sparse allocations traditionally done for IPv4. They are massively over allocating IPv6 address space in the hopes of not having to re-allocate address space and also simplifying the routing tables at the same time. Seems like a good plan out of the gate for now but I wonder what challenges there will be with some of the multi-national organizations that are getting IPv6 address block from multiple regional registries and each request is including all their "sites." Arguably the IPv6 address space is so large it really doesn't matter but I think more on principle that it is potential wasteful. Thoughts?
- Ed

Presenting Deploying IPv6 in a Microsoft Enterprise Network at Pacific IT Professionals

I will be presenting an updated version of my Rocky Mountain IPv6 Task Force presentation tomorrow at the Pacific IT Professional User Group meeting at Microsoft's office in San Francisco on August 2nd. It is a free and open meeting to attend. Only request if for everyone to RSVP so they know how much pizza to order. Hope to see you there.
- Ed

June 2011 Microsoft Springboard Series Insider Article - What You Should Know About IPv6

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 interface
netsh interface ipv6 show address
netsh interface ipv6 show route
You can turn off 6to4, ISATAP and Teredo with the following netsh commands:
netsh interface ipv6 6to4 set state state=disabled
netsh interface ipv6 set teredo disable
netsh 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?

1. Acquire Provider Independent IPv6 address space through a regional registry.
2. Do native IPv6 peering or use a tunnel service to get your address space routable.
3. Get an external firewall and external routing working.
4. Test public IPv6 with external DNS, mail and perhaps a test web server.
5. Evaluate transition services as needed - perhaps you have a case for using ISATAP.
6. Test your applications in a lab - do NOT make your corporate or production users guinea pigs! Additionally Microsoft has an IPv6 Test Lab available for Windows 7 and Windows Server 2008 R2.
7. Get internal IPv6 routing, DNS & DHCP working (phases are possible).
8. Dual stack your servers.
9. Provide dual stack to your workstation virtual local area networks (VLANS).
10. Deploy a VPN dual-stacked solution.

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