My presentation from Microsoft TechEd in Houston (last US TechEd since it is now Ignite) is available on YouTube, in addition to Channel9, so if you have some time and want to hear the impacts of IPv6 on Private Cloud jump over and watch or you can play it from the embedded video below.
If you want a copy of the slides you can download them from the Channel 9 link along with the video itself too if you want to watch it while offline.
One of the recent questions I am getting around IPv6 deployment has to do with connecting remote sites and making branch offices highly available without using BGP. Today, with IPv4 it is not uncommon for a typical branch office to have two ISP connections, each with unique IPv4 ISP address space (provider assigned). The branch site will have a router or firewall that will make use of both connections by leveraging NAT and some sort of tracking or performance algorithm to determine which connection to use. It is able to do this because the solutions utilized NAT to obscure the actual IPv4 addresses used by the hosts. It is cost effective and works for many scenarios where some sort of higher availability and/or failover is desired for these sites without the complication of BGP. All these configurations allow the remote site to have local Internet hop off without backhauling the traffic across WAN or VPN links back to the corporate office.
So the natural question that comes from this IPv4 topology solution is, how do I do this in IPv6?
The answer is not as clean and neat as many would like it to be but there are several options you can utilize. Let's cover each of them and go over their merits and shortcomings.
1. Use both IPv6 provider assigned address ranges in your remote branch location. Optionally use NPTv6 on the router(s) to handle failure scenarios of ISP's and to provider faster failover.
2. Use a single IPv6 provider assigned address range in your remote branch location. Use NPTv6 on the router(s) to handle failure scenarios of that primary ISP. Simplifies host address configuration.
3. Use VPN to extend your primary provider independent address space to the remote branch for routing. Optionally use NPTv6 on the router(s) to handle local Internet hop off. Simplifies host address configuration.
4. Use ULA in your branch location and use NPTv6 on the router(s) to direct traffic to the appropriate ISP. Simplifies host address configuration however complicates routing and global reachability.
5. Upgrade the site to use provider independent configuration and do BGP and run a single prefix that is routable. No NPTv6, no PA address space and highly available.
After describing these options I am often asked, which is the best? What configuration should be used? The first option almost everyone selects is 4 - it looks and feels like what they operate with IPv4 today. I can't blame anyone for picking that initially, especially given it familiarity. But I believe ULA should only be used in narrow situations with an eye on preferring global unicast address space at all times. After picking the option of global unicast address space the next sorting preference is provider independent address space. This is a tough one and for many is not a viable option due to a variety of reasons. Costs, operational skills to run BGP and slightly more complex routing configurations, hardware requirements, plus often it can be political. So, with a preference for global unicast, likely provider assigned address space where are we left? Options 1, 2 and 3 are all still possible. My next rule is to try and simplify host address configuration and try and make RFC 6724 as predictable as possible. This means preferring a single prefix from one service provider to address the site. Just like in IPv4 you will likely prefer a particular connection due to speed, cost or some other criteria that is dictated by business decisions. Use the address prefix that comes out of that decision and address the site. Use a VPN connection from the other ISP to connect the remote site back to your corporate via routing and set up NPTv6 if needed. This solution address almost all use cases and has the advantage of being predictable from a routing and topology basis.
If you have existing PI space from a regional registry like ARIN then consider extending the address space to the remote site via VPN. If you require local Internet hop off you can then enable NPTv6 and leverage that. Remember, NPTv6 brings all the penalties of potential protocol brokenness. There can be situations where certain applications and protocols will not function correctly so NPTv6 is an undesirable tool for that reason. This is one of the reasons that I avoid ULA and why making use of ULA is so far down my list. At least with a true global unicast address you can guarantee proper IPv6 functionality in all cases.
To make things even more challenging - there are very few NPTv6 (or older NAT66) implementations available. So those that think NAT and IPv6 is a happy future, think again.
I hope this helps clarify how I come to my design recommendations and why I think ULA is a poor option for many situations and how leveraging NPTv6 today will be a challenge.
I had a few errors in the podcast that I wanted to correct. First, ULA (Unique Local Addresses) are from the fc00::/7 prefix and the useable space is fd00::/8. To clarify, VLSM (variable length subnet masking) in conjunction with CIDR (Classless Inter Domain Routing) are complimentary and what enabled better utilization of IPv4 address space along with more granular routing of address blocks. Third, the M flag in the RA is for Managed and not Manual. I am bad about saying manual when I really mean managed so apologies about that. I think the rest was pretty much on target.
There is still time to sign up for the North American IPv6 Summit hosted by the Rocky Mountain IPv6 Task Force in Denver, CO. It is the premier IPv6 event in North America for sure and the list of speakers is a who's who of the IPv6 world. I'll be attending and helping out by providing free time to review through an IPv6 Address Planning worksheet. If you are interested in IPv6 at all and have the time, please come join me.
Finally, the California IPv6 Task Force is having our quarterly meeting next Weds, Sept 17th at the Cisco campus in San Jose. You can find details on our meetup site. The event is open for anyone to attend, simply RSVP so we know how many folks to expect.
There are several opportunities to get some IPv6 education outside of taking a formal training course. In September the North American IPv6 Summit hosted by the Rocky Mountain IPv6 Task Force will happen in Denver, CO. This is the primer IPv6 event that happens in North America, hands down with a great line up of speakers and some incredible pre-conference tutorials that you can attend. If you can make the time (it is a super cost effective event so don't complain about the cost! - especially compared to things like Cisco Live, TechEd, VMworld, OracleWorld, etc.) I can assure you the speakers and content will be worth the time investment.
If you are in New York in October, I will be presenting at Interop doing an IPv6 bootcamp. I will cover a variety of IPv6 topics to help you get up to speed quickly using the protocol. You can get more details about me session here. Interop is always a great show, I hope they expand the IPv6 training and education but I am grateful they at least have my session for folks to attend if they are interested.
In November, the California IPv6 Task Force and gogo6 jointly run the gogoNET Live IPv6 conference in Silicon Valley. This will be the 5th year of the event and the best part is that it is principally going to be an online broadcast event again this year. It is a super cost effective event to participate in, regardless of where you are located in the world. The topics will focus on SDN, NFV, IOT and how IPv6 is leveraged in all of those technologies. IPv6 really is the underpinning for a lot of innovation happening in other fields, it just isn't talked about as much.
So, there you have it, a few in person IPv6 events you can attend. Obviously you can get online education and resources from a bunch of places. ARIN has a wonderful wiki you can use, RIPE has a great IPv6 resource page too.
Some of you who only keep track of me via my blog site might not realize I have been producing content (regular blog posts for sites like the Infoblox IPv6 Center of Excellence or guest posts here and there) on other Internet properties. I thought I would quickly jot down where some of my other posts are in case you are interested in reading them.
Guest blog post on ARIN as a follow up to my Interop presentation on IPv6
Date: July 22, 2014
Title: Getting Serious About IPv6 – Go Big or Go Home