Wednesday, March 25, 2015

Interop - Las Vegas - How to Get Up and Running With IPv6 -- Without Destroying Your IPv4 Network!

http://www.interop.com/lasvegas/

I have been building out the content for my workshop at Interop in Las Vegas at the end of April and I am pretty excited about what I get to cover for folks attending. I will be doing a workshop titled "How to Get Up and Running With IPv6 -- Without Destroying Your IPv4 Network!" and (no surprise) it is how to really start using IPv6. I encourage you to sign up for my workshop and for Interop, it is a great show and the individuals presenting and running the event are really unique industry insiders. You can get a registration discount of 25% by using SPEAKERVIP! when registering for the event. You have until Friday, April 25th to use that code, after that you pay full price! My workshop is on Monday, April 27th from 1 to 4:30PM followed by a small reception.

To give you a taste, here are some of the items I will cover:
The Big Picture - You need an IPv6 Plan
 Assessment, Training, Planning and Design, Proof of Concept, Deployment

Worksheets for the following:
 Fundamentals, Addressing, Prefix, DHCPv6, DNS, Happy Eyeballs, Mobile and Cloud

Additional overview worksheets on:
Technical and Operational Worksheet
Planning and Design Worksheet

Also, review of key design differences between IPv6 and IPv4 covering things like:
Network address planning
Where is my NAT?
Protocol translation - transition technologies

Finally, wrap up with some demos and a limited lab (due to resource constraints)

And my Interop abstract (so you know what is published) is:
The most common IPv6 deployment is in conjunction with an existing IPv4 network. However, knowing the operational differences between IPv4 and IPv6 can be difficult, and understanding how hosts on your network will behave can be an even bigger challenge.

This workshop focuses on getting IPv6 up and working on an existing IPv4 network, including how to understand what you've deployed and how to use some common tools with IPv6. We'll look at typical frustrations such as setting the right IPv6 Router Advertisement flags, DHCPv6 settings, how ICMPv6 will impact your IPv6 deployment, and much more!

Attendees will:
  • Learn how to set up and configure IPv6
  • Determine the best operational settings for IPv6
  • Look into common dual-stack challenges
  • Review common tools to understand how IPv6 affects OS behavior

Who should attend:
  • Network, security, storage, system and virtualization administrators, architects and designers who run and maintain IPv4 infrastructure and are looking to add IPv6. Also, those looking to build labs, proof of concepts or smaller deployments with IPv6.
###

I look forward to seeing you at Interop, please don't be shy to come up and introduce yourself to me if you see me at the event. Also, I am more than happy to sign copies of my book if you happen to have it with you. I will have a few I will be giving away during my workshop too!
- Ed

Wednesday, March 11, 2015

RunAs Radio Show 411 - IPv6 in 2014

I was lucky enough to talk with Richard Campbell about IPv6 and how things had gone in 2014. We chat about a variety of things related to IPv6 and it is always and honor and great fun to be on RunAs Radio. Check out the show yourself at the RunAs Radio website.
Enjoy!
- Ed

Monday, February 16, 2015

New Posts on Infoblox IPv6 COE

I've been busy generating content for others and my blog has suffered as of late, I apologize for that. I do have some posts that might be of interest over on the Infoblox IPv6 Center of Excellence Community Blog site. Specifically, I have kicked off the year talking about what tasks you need to do for your IPv6 plan. I will update this post as the remaining blog posts come out.

The first was an overview talking about having a plan and can be found at:
https://community.infoblox.com/blogs/2014/10/28/first-steps-ipv6-adoption-having-plan

The next addresses assessments:
https://community.infoblox.com/blogs/2015/01/19/kick-2015-first-phase-your-ipv6-plan-assessment

There will be future posts that cover the following:
Training
Planning and Design
Proof of Concept
Deployment
Operate

I have also been busy developing a Pluralsight course on, surprise, IPv6. I will post a link to that once it is completed. Don't forget you can always pick up my book if you want more in-depth knowledge around IPv6 and Windows. My book is available on Amazon in print or kindle at http://tinyurl.com/Practical-IPv6 - if you like the book please leave me a review, I'm always interested in hearing back from readers.

In the mean time, I will try and add some more content around private cloud, automation and containers as I have been spending time working and exploring those topics for work.
- Ed

Wednesday, December 03, 2014

How IPv6 Impacts Private Cloud Deployments from Microsoft TechEd, Houston 2014

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.
Enjoy.
- Ed

Wednesday, November 19, 2014

Dual ISP, no BGP and IPv6 - what do my design options look like?

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.
- Ed