Wednesday, April 23, 2014

ARIN moves into Phase 4 and is down to their last /8 of IPv4 - it is time for IPv6

It is official, as of today (April 23, 2014) ARIN and by extension North America has run into the final phase of IPv4 address allocations. They are down to their last /8 and therefore the largest allocation now will be a /22 along with showing a use case for transition over to IPv6. If you have no transition plan, you can't even get that last /22.


 You can see more information about Phase 4 at the ARIN press release. This is a huge deal for the Internet community and will likely change some corporate and enterprise adoption plans and thinking in the near future. If you are curious, it looks like Akamai was the big winner with the allocation going to them and tipping the inventory level.

So for all of you holding off thinking IPv6 will never impact them, it is time to start planning and figuring out your design and implementation schedules. You will have a bit of time for the service providers to burn through their existing inventory of IPv4 but after that you will have to purchase IPv4 at the going market rate. It makes IPv6 look more and more attractive.

If you want some help getting started in a lab or deploying and you run Windows you might want to pick up my book.

Practical IPv6 for Windows Administrators

Welcome to a brave new world, I think I need to pick up my "the world is ending" sign and go walk around downtown San Francisco for the day.
- Ed

Saturday, April 05, 2014

Post Interop Las Vegas - IPv6 update

Thanks to everyone who attended my IPv6 presentation at Interop. I was pleased with the number of attendees who chose to participate in my session especially being the last timeslot of the day. Many who attended wanted the slides so I am making them available via slideshare. You can also download the PDF from the Interop website (attendees only - requires username and password)

If you have more questions please reach out to me via twitter or by email (My name at and I will do my best to answer any questions around the presentation and about IPv6.
 - Ed

Tuesday, March 11, 2014

Presenting on IPv6 at InterOp in Las Vegas - April 3, 2014

I was delighted when my colleague Ethan Banks (of PacketPushers fame) asked me to present on IPv6 at InterOp. The presentation audience is a slightly different for me so I have had to change some of my content and get a bit more creative, all good things. The title for my session is:
Getting Serious about IPv6: Go Big or Go Home

It is really focused at Enterprise Network Managers, Directors of IT and CTO types rather then the typical networking nerd that might attend an IPv6 session. I felt it was important to start explaining IPv6 to these professionals so they really understand what is happening in the industry. For the session the key takeaways are:
    Why you need to move to IPv6 for your Enterprise
    The impact to your business of staying on IPv4 only
    What to do next to get started with IPv6 in your Enterprise 

My session is on Thursday, April 3rd at 4pm and the show is in Las Vegas. I encourage you to register for the event not just because I am presenting (though that should be good enough on its own!) but also because of the impressive list of other speakers.

I believe InterOp makes the contents available after the event so I will update the blog when that happens. I hope to see you at my session!
- Ed

Update: apparently InterOp has a really good discount going on right now until March 17th for the show. If you use the discount code 40PERCENT you will get, surprise, 40% off the total access pass. 

Thursday, January 16, 2014

Getting your first IPv6 address allocation from ARIN

The American Registry for Internet Numbers or ARIN has put out a great little PDF you can download on how to get started with getting your first IPv6 allocation. For those who have not done this it can be useful to have an outline about what to expect in the process and this provides that.
It is interesting to note that they give the same site to prefix allocation chart as their website which is outlined below:

 Number of Sites   Prefix Block Size 
1  /48
2-12  /44
13-192  /40
193-3,072  /36
3,072 - 49,152  /32

You can find the details for how this actually works on the ARIN website.

I would expect most enterprises to fit in the /40 to /36 category as ARIN's definition of a site is relatively broad. They did this intentionally and as you can see in the definitions that follow, you can argue your single work from home user would classify as a site.

From ARIN's website:
" Standard sites
A site is a discrete location that is part of an organization’s network. A campus with multiple buildings may be considered as one or multiple sites, based on the implementation of its network infrastructure. For a campus to be considered as multiple sites, reasonable technical documentation must be submitted describing how the network infrastructure is implemented in a manner equivalent to multiple sites.
An organization may request up to a /48 for each site in its network, and any sites that will be operational within 12 months. Extra-large sites
In rare cases, an organization may request more than a /48 for an extra-large site which requires more than 16,384 /64 subnets. In such a case, a detailed subnet plan must be submitted for each extra-large site in an organization’s network. An extra-large site qualifies for the next larger prefix when the total subnet utilization exceeds 25%. Each extra-large site will be counted as an equivalent number of /48 standard sites."

Remember, if you run labs, dev and test networks that might have to simulate an entire site then you need to include each of those as sites and not as a single /64 subnet in your design and request to ARIN. Otherwise you will not have enough address space to build out those test environments that you might require and you will have to go back to request address space.
- Ed

Monday, January 13, 2014

The IPv6 Show - IPv6 in the Enterprise? Why Bother?

The IPv6 Show
Bruce Sinclair with gogo6 is running a great podcast on IPv6. The IPv6 Show has had some fantastic guests already like Scott Hogg, Joe Klein, Jeff Doyle and Rene Paap.

I've personally really enjoyed listening to the show and I encourage you to listen to past shows and to follow the podcast if you are interested in IPv6 at all. I was fortunate enough to have Bruce ask me onto the show so please have a listen.

Podcast: Download for a copy and to play on iOS devices
Click here to Subscribe to "The IPv6 Show" on iTunes!

I am looking forward to hearing from other IPv6 industry experts that Bruce interviews in the future on the show, I think it is one to keep any eye on!
- Ed

Saturday, December 28, 2013

Practical IPv6 for Windows Administrators is available!

Practical IPv6 for Windows Administrators

My book Practical IPv6 for Windows Administrators from Apress is officially published and available to order. You can order a printed copy from Amazon, or a Kindle version and Barnes and Noble has the printed version available now too (a Nook version should be available shortly.)

A thank you to Richard Hicks and Jason Jones who did the technical review for the book. They were critical in so many ways and their feedback and honest opinions about things in the book were really valuable to me. The end result is much improved due to their hard work.

I also want to thank Jonathan Gennick my Lead Editor and Ana Panchoo my Coordinating Editor, both with Apress, for helping make the book writing process easy (as easy as you can make writing a book.) They really were fantastic to work with and considering this book was produced in 5 months they really had to work hard to make it all happen. If you are a technical author or want to become one I would recommend Apress. You can review through their materials on their Write For Us section of their website.

Finally, please don't be shy and let me know if the book was on target. I worked on trying to solve some of the design, operational and practical issues that come up with figuring out how to get started with IPv6 and Windows. There is always room for improvement so let me know!
- Ed

Wednesday, December 18, 2013

IPv6 is like global warming

I recently was on twitter going back and forth with some colleagues on the topic of IPv6 (shocking, I know) and I said the following:

"IPv6 is like global warming, sea level rise is easy to ignore (or deny) but it will impacts a crazy number of people"

This resonates with me. The fact that regardless of how you feel about global warming (man made, natural fluctuation, curse from a $deity) the effects are what matters. There is sea level rise (it is measurable, we are measuring it, it is going up) and given the fact that a very high percentage of the world populations live close or on the edges of the oceans they are going to be impacted.

There are practical ways to deal with this. Most agree the sea level change isn't going to jump up 3+ feet overnight (outside of storm surges, etc.) so it is possible to plan and take corrective action. There are cities and governments in the world where this is happening today. They are being proactive and realize it will take a long time to get everyone to adjust to this new change (building codes, zoning, etc.) There are also those that are not taking these actions. Finally there are those unfortunate few who can't address it even if they wanted to, like some small remote islands.

We won't know the final outcome and impact until years later. Who did the right strategic move and planned, implemented and were ready for the eventual sea level rise? It is analogous to those who plan, implement and deploy IPv6. In both situations you can wait. But eventually you must deal with the issue. Will you be ready when the sea level rise happens? Will you able to execute on IPv6 when your company needs you to?

So perhaps the global warming community can say:
"Global warming is like IPv6, IPv4 depletion is easy to ignore (or deny) but it will impact a crazy number of people"

How is that for turning it back around!
- Ed

Tuesday, December 10, 2013

IPv6 NAT66 and NPTv6 - it seems there is still a lot of confusion

I've written previous posts on NPTv6 but it seems I didn't do a particularly good job explaining the different between NPTv6 and NAT66 and there is still a lot of confusion understanding what the actual difference is between the two. While both are doing network translation they are doing it differently.

The difference is pretty simple. NAT66 performs the same function we have with NAT44. It is a stateful network address translation on a router or firewall. It will take an IPv6 address on one network interface and translate it to a new IPv6 address on the other network interface and forward the packet. It may perform some sort of application fix up to keep certain protocols and applications from having problems. It requires resources (CPU and memory) on the router or firewall to do this and the returning traffic will have to come through the same device because it is keeping a state table of all the translations it is performing.

NPTv6 is different then NAT66 in that only the leftmost prefix portions of the address are translated. This means that the device doing this translation do not need to keep state at all. So NPTv6 is stateless and therefore in theory can scale better and also be distributed across many devices doing the same function (regardless of forwarding changes and asymmetrical routing). The internal prefix and the external prefix sizes must match so if you want to use NPTv6 you need to do some work to make sure things match up. In other words, your internal network may have a /64 ULA prefix that you want to use NPTv6 to give it access to the IPv6 Internet. You will need a /64 of global unicast address space to allow the router or firewall to do the NPTv6 function with. If you have a /48 internally that you want to use NPTv6 with then you will require a /48 for that externally.

There are some minor variations of these two. NAT66 can, in theory also provide PAT functions allowing the overload of a single IPv6 address by multiple IPv6 addresses behind it. This really is not needed with IPv6 at all as there are more than enough IPv6 addresses to go around. In theory SLB64 looks like NAT66 because it is providing a shared VIP to access a resource and translating traffic appropriately.

As a general rule of thumb, those in the IPv6 community see NPTv6 as a potential tool to solve some corner case issues and they see NAT66 as not desirable. There really is no reason to run NAT66 and if you do require any sort of NAT function then you should be using NPTv6. Unless we want to repeat all the mistakes we have made with NAT44 over the years (and now NAT444 with CGN solutions) then adopting NAT66 is a poor choice.

Obviously this debate is ongoing and it could end up that NAT66 ends up winning but I am hopeful that won't be the case.
- Ed

Sunday, December 08, 2013

Follow up to my IPv6 and ULA post plus some thoughts on design and IPv6 behavior

I've gotten some interesting comments and questions in regards to my IPv6 ULA (Unique Local Address) post and I wanted to outline the questions and then follow up with my thoughts and some high level design discussion.

The first question is around the situation of multiple ISP connections without using BGP and Provider Independent (PI) addresses or alternately switching from one ISP to another. The argument is pretty straightforward, you don't want to have to renumber your servers, network links and other infrastructure when changing ISP's because the IPv6 address space you have is allocated from that ISP. That IPv6 address space will no longer be yours when you change from ISP A to ISP B. So, alternately you can use ULA for your network, server and even client devices and only use that ISP IPv6 address space at the edge, similar to how you implement IPv4 today. This requires the use of some sort of NAT translation at the edge.

The second question is a bit of a refinement of the above that argues you should use ULA for all internal hosts and your LAN and WAN resources so you don't have to renumber if you change ISP's but also so you have a consistent address prefix preference for internal traffic to register with DNS.

I think those really are the main pro ULA arguments I have heard so far. Let's tackle the first part which is really all about flexibility in choosing and changing your ISP and reducing the IPv6 renumbering costs to a fractional degree. The second one I will cover in a different post.

The following diagrams shows the multiple ISP connection configuration which is no different than migrating from one ISP to another. We start with ISP A on the left and will be moving to ISP B on the right. Our initial network configuration will use ISP A's IPv6 Provider Assigned (PA) address block and our goal is the move to ISP B's IPv6 Provider Assigned (PA) address block. For a duration of time you will have both ISP A's and ISP B's IPv6 address blocks active on your network. The next diagrams (Figure 2 and 3) are what everyone thinks they want to deploy. It utilizes some sort of NAT technology at the Internet edge and assumes you will only use ULA for the "internal" network.

Figure 1. Dual connections while migrating service providers

Figure 2. ISP 1 with NAT66

Figure 3. ISP 2 with NAT66

The primary problem with the ULA solution people want is that there are no good production quality NPTv6 implementations out there to run on a firewall or edge Internet device today. This limits your ability to actually deploy that solution so you are left with NAT66 (not a good option in my opinion). Furthermore, NPTv6 still breaks many end to end features for applications relying on the underlying networking protocol not doing NAT. Application developers will still have to build NAT traversal mechanisms into their apps even though we were not supposed to need them with IPv6 at all. The only advantage you will gain is that with NPTv6 you have a stateless solution for NAT as only the prefix is actually changed. This reduces the amount of resources required on that Internet edge device greatly compared to the same solution with IPv4. An additional option is to go with NAT66 (which is available from some network manufactures) but which make IPv6 even more brittle and introduces every one of the NAT/PAT problems we have with IPv4 only on a much larger scale. I consider this solution a huge mistake and using it roles back all the progress and design work that the architects of IPv6 put into the protocol.

The slightly more difficult dual ISP PA migration (Figure 1) solution will actually work just fine without ULA. You will have to do some planning to do renumbering however depending on your design this could potentially be relatively easy. The most difficult resources to renumber would be your LAN and WAN infrastructure and your servers. Client devices should be dynamically obtaining their IP addresses (IPv4 or IPv6) and should not care greatly if their network address prefix changes over a weekend or even within the day. IPv6 has no issue with running both PA IPv6 prefixes at the same time nor does it require ULA to do this function. You might gain some time back on larger LAN and WAN networks on not having to renumber and this could be true for servers also however you will have to write additional firewall rules and you will still have to give them global unicast addresses if they need to talk to the public IPv6 Internet at all (remember, limited or no NPTv6 support today). This means you still have to touch the device to change it over from one IPv6 prefix to another. If it does not have the requirement for being able to get to the public Internet at all then there is a use case for using ULA. I see this as a secure network and I argued in the previous blog post that a secure network would be a legitimate use case for ULA.

ULA may buy you a small amount of stability in avoiding some address renumbering but I would argue that a proper DDI solution solves almost all the issues using DDNS and name to IP address resolution. What you gain from ULA to avoid renumbering you will likely have to pay back 10 fold in NAT traversal issues and pain.

A quick question, how often are people changing ISP's for small to medium sized businesses? I think some of the renumbering argument assumes this happens far more often than it does. For many medium to larger enterprise customers they will likely get Provider Independent IPv6 address space and utilize BGP to advertise to multiple ISP's at once (Figure 4). They do not require NPTv6 and even if they need local Internet hop off at a branch location they would simply deploy both PI and PA IPv6 prefixes at that site and let RFC 6724 solve the source/destination matching (Figure 5). They can gain more granular control of the routing behavior if they modify the prefix policy tables.

Figure 4. Dual homed IPv6 BGP peering

Figure 5. IPv6 PI and PA with local Internet hop off

As for those that are dual homing but not running BGP they do not require ULA or a NAT solution, simply run both IPv6 PA address space on the network (Figure 1) and let RFC 6724 solve the source/destination matching. If you want more control you can manage the prefix policy tables on your hosts or do some routing policy work within your network. Even so, if you are doing dual homed but no BGP you likely don't have a large enough network to care or bother with those efforts. Either way, I believe it is still simpler to use both service providers IPv6 PA space than to deal with ULA and NAT.

Thoughts? What other ways to you see ULA being an advantage over global unicast IPv6 addresses in your network?
- Ed

My book is available for pre-order on Amazon or you can order directly from the publisher Apress

Monday, October 21, 2013

I am speaking at the IT Roadmap event in San Jose Oct 24

I will be doing a presentation on IPv6 at the Network World IT Roadmap event at the San Jose Convention Center on Thursday, Oct 24. If you are interested there is still time and room to registered for the event. My presentation is "IPv6, Now is the Time" and my long time friend and colleague John Hoffman from Oracle will be presenting with me talking about how Oracle is doing their IPv6 deployment and some of the  challenges and issues they have run into over time.
If you are in the area I encourage you to come attend the event. There is a wonderful line up of topics and presenters so it will be worth your time to come and attend.
- Ed

Thursday, October 17, 2013

Network Field Day 6 - Post Mortem

It has been close to a month since I participated in Network Field Day 6 and I am finally getting a chance to write up my thoughts and feelings about the experience overall but also the companies that participated and hosted all the delegates to show us what they are doing.

First, a quick perspective on what Stephen Foskett is doing with Tech Field Day (and all the related events he is involved with) - simply amazing. I can't say enough about how impressed I was with the event. The engagement and quality of the delegates was fantastic and the overall experience of interacting and meeting folks of that caliber was really special. For that alone I give a tip of the hat to Stephen, Tom and Claire for all their hard work in pulling together such a unique opportunity and event.

Second, I have a slightly different perspective of things being a first time delegate and perhaps not as prolific a blogger as some of the other delegates. I thought since I have had some time to think about who I saw at NFD6 I would give you my impressions of the companies who presented and which has had a lasting impact of still being top of mind for me.

With that, I would say the lasting impact company has to be ThousandEyes. Thousand Eyes has an IT performance management platform that I can see a ton of different customers using to solve all sorts of unique problems that until now are relatively difficult to do.

First of all, the easiest way to see how their product works is to check out their videos that gives the overview. What struck me right away with what they were doing is how obvious it was and then wondering why no one had done that before! To me, that is the sign of a great product, when it just clicks and makes sense.

So what is unique about what they are doing? It is the marriage of good graphical monitoring solution with public and private agents but designed for monitoring SaaS applications. They aggregate information from both private agents (that you can run from any location you control) and public agent sites that they maintain. In addition, their service and design works so well that major SaaS providers are using it themselves to measure their performance. If you are responsible for measuring and reporting on SaaS SLA's at all than you should be seriously looking at what they are doing. That really is how they are unique. There are lots of performance monitoring tools out in the market but this is the first that marry together these functions and in an elegant way that is very intuitive.

To be fair, I was impressed with many of the other manufactures that participated in NFD6 and I will likely take a moment to put a blog article together on them also but of all the companies Thousand Eyes really stood out. So there you have it, a company you should really go check out what they are doing.
- Ed

Disclosure and Disclaimer:
Thousand Eyes (and other manufactures) participated in the Networking Field Day 6 event, thus indirectly covering some of my travel expenses. At no time did they ask for, nor where they promised any kind of consideration in the writing of this review.  The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone unless I specifically blame someone else for my mistakes, which is uncool but might happen.

Wednesday, September 25, 2013

I am speaking at TechMentor in Las Vegas Sept. 30 - Oct. 4 on IPv6

For those of you who are Windows admins and interested in learning about IPv6 I am doing a 3 hour session at TechMentor in Las Vegas next week, September 30th through October 4th. You can still sign up for the event. The conference over all is an excellent chance to learn from some of the best in the community, Greg Shields, Don Jones, Mark Minasi and many others. The exciting part is the change that TechMentor has put in place for their format, it is all hands on labs and deep dive sessions so you really get to learn a lot. The presenters aren't trying to sprint through content and can take the time to explain things and have much more engaging discussions about topics of interest.

My session is Mastering IPv6 for the Inspiring Windows Sever Administrator and I will be taking you from the basics of IPv6 through to some practical advise and a demo or two. So please join me in Las Vegas, perhaps we can chat all about IPv6 and what is happening with it. If not, we can always talk PowerShell, Hyper-V, System Center and Azure!

My session description:
Have you been scratching your head wondering what this IPv6 thing is all about and how it might impact you? Have you seen an IPv6 address and wondered how in the world do I subnet that? The first part of the session is focused on explaining the basics of IPv6 and how it is both different and similar to IPv4. The second part is how to set up a basic working configuration, best practices and common problems you may run into in deploying IPv6. We also cover the default assumptions Microsoft has in place for IPv6 and how that impacts your decisions and how you should manage your environment.

Hope to see you in Vegas!
- Ed

Friday, September 20, 2013

IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them

I am often asked interesting questions by fellow IT professionals about IPv6. Some are worthy of a blog post or two so here it is. The subject of IPv6 Unique Local Address or ULA (which is one of the unicast IPv6 address types) seems to be getting more attention now that IT professionals are actually looking at how to deploy IPv6. I thought I would share some brief information about ULA and follow up with my thoughts about it.

ULA is a unicast address type and is limited to the fc00::/7 prefix. This means the prefix has a fixed binary value of 1111 110x with ULA having the concept of a local flag bit (x) which is the 8th bit. This means the prefix is divided into fc00::/8 and fd00::/8. The local flag value of 0 hasn't been defined and therefore should not be used at all which eliminates the fc00:/8 prefix from being used. The local flag value of 1 indicates that the prefix is locally assigned. That means the only valid ULA addresses to use today are from the fd00::/8 prefix.

There have been a few interesting efforts to coordinate ULA prefix allocations. I have no idea why you would do this but you can check it out at SixXS's site. The reality is, fd00::/8 by definition is locally assigned and there is an algorithm defined in RFC 4193 that helps in generating a unique prefix out of that range to help avoid collisions or you can put your MAC address into the SixXS site and it will generate a prefix for you. You can find how the algorithm works in Section 3.2.2 if you want more details.

So what has sparked all this interest in ULA? I think it is happening because many IT organization think deploying IPv6 should be done in the same manner as IPv4. If you spend any time around IPv6 professionals you will quickly learn that IPv4 thinking doesn't apply when designing IPv6 networks. As an example, the role of NAT and address conservation are entirely thrown out the window. I think there is still a lot of confusion around the role of NAT and many IT professionals still consider NAT a security feature. NAT never was intended to be (and never functionally was) a security solution. All NAT provides is a way to conserve the use of public IPv4 addresses. If you disagree, I'm sorry, you are wrong.

Getting back on track, the analogy is often given that ULA is like IPv4 RFC 1918 address space. I believe this triggers people to think they should use ULA in the same way they are using RFC 1918 today. In other words, assign ULA everywhere on their internal network and run a NAT solution at their edge via a firewall or router. This looks exactly like what they do in IPv4. It also turns out that this is completely WRONG for IPv6.

It actually isn't accurate to say that ULA is like RFC 1918 address space. RFC 1918 address space was specifically set aside for the purpose of running NAT because of the shortage of public IPv4 addresses. There is no shortage of IPv6 address space and there will not be any within your lifetime, your children's lifetime or your grandchildren's lifetime or, well, you get the picture. So how is ULA like RFC 1918? The design of ULA was to have an IPv6 address space that would not route on the public IPv6 Internet - ever. In that capacity, ULA and RFC 1918 addresses are the same, neither was intended to be used on the public Internet at all. ULA was designed for labs or other resources (think secure military uses or maybe internal networks at power plants for example) that NEVER need to (or should ever) talk to the global Internet.

Let me repeat that, you use ULA when you never want to talk to anything on the Internet. I have seen many IT professionals say there should be NAT solutions in IPv6. There are some limited corner cases where solutions like NPTv6 (which is network prefix translation for IPv6) might solve some problems however I am not aware of any production ready implementations of NPTv6. In fact, the NPTv6 RFC is still in experimental status, see RFC 6296 and the former solution of NAT-PT has been moved to historical status, see RFC 4966 so really you have no robust NAT solution to date outside of server load balancing solutions like SLB66.

So what do you do? Simple, you reject your IPv4 ways of thinking and adopt the IPv6 way of thinking. You deploy global unicast IPv6 addresses throughout your network and use a stateful packet inspection firewall to control traffic and enforce security rules. You build good routing policies and leverage host based firewalls to enhance your security posture. In fact, you do all the same security measures you do for IPv4, you just happen to be using global unicast IPv6 address. Why? Because we have enough IPv6 addresses that we don't need NAT anymore.

What advantage do you gain by doing this? First, you don't break protocols that tend to embed address information in their session process. NPTv6 will still break protocols requiring firewalls and other network devices to try and do "fixups" or intelligent repairs on the fly to sessions. Why are we wasting time on that when if you simply use global unicast addresses with no network address translation then the protocol doesn't require any special handling.

Finally, it is easier to manage, complies with every design recommendation you will find out there on deploying IPv6 and reduces the chance you will have breakage for a service later (assuming your firewalls aren’t blowing it up – but at least you only have to look in one place for that issue).

So there you have it. In summary, ULA is appropriate for a lab, a proof of concept, a super secure network and maybe an out-of-band control network. Even then, I would still argue you could do all of those functions with global unicast addresses and simply put the correct routing and firewalls rules in place. ULA is designed to never be routed on the public IPv6 Internet and as a result you should not be assigning ULA to hosts in your network unless you have the correct use case. Otherwise, stick with global unicast IPv6 addresses. Do IPv6 right the first time so you don't have to go back and do it again. As a final thought I give you Andrew Yourtchenko's fun NAT YouTube video.

- Ed

Tuesday, September 17, 2013

Cricket Liu presenting on IPv6 at Dyn Geek Summer Camp

Cricket Liu who is the VP of Technology and Architecture at Infoblox recently gave a wonderful IPv6 presentation at Dyn's Geek Summer Camp that I encourage you to watch. I have embedded it in this post for your viewing pleasure. He has some great points about the issues with IPv4 depletion and what will be happening long term with IPv6 adoption.

- Ed