Category: Workshop

A month ago Stephen Foskett complained about lack of Microsoft’s support for FCoE. I agree with everything he wrote, but he missed an important point: Microsoft gains nothing by supporting FCoE and potentially a lot if they persuade people to move away from FCoE and deploy iSCSI.

FCoE and iSCSI are the two technologies that can help Fiber Channel gain its proper place somewhere between Tyrannosaurus and SNA. FCoE is a more evolutionary transition (after all, whole FCoE frames are encapsulated in Ethernet frames) and thus probably preferred by the more conservative engineers who are willing to scrap Fiber Channel infrastructure, but not the whole protocol stack. Using FCoE gives you the ability to retain most of the existing network management tools and the transition from FC to FCoE is almost seamless if you have switches that support both protocols (for example, the Nexus 5000).

You’ll find introduction to SCSI, Fiber Channel, FCoE and iSCSI in the Next Generation IP Services webinar.

Quick summary for the differently attentive: Even without the DNS processing, NAT-PT and NAT64 differ from the perspective of peer-to-peer applications. The differences don’t matter for IPv6 clients connecting to IPv4 servers.

Whenever I’m talking about NAT64, someone would say “we’re already using it”. As it turns out, they’re usually using NAT-PT, which looks a lot like NAT64 from afar (after all, they both allow IPv6-only clients to connect to IPv4-only servers). However, there are significant differences between the two, the most important one being DNS64, which handles DNS processing completely outside of the forwarding path (NAT-PT has embedded DNS Application Level Gateway, which was one of the major reasons NAT-PT was declared broken beyond hope).

A while ago I was criticizing the network-blindness of the storage industry that decided to run 25-year old protocol (SCSI) over the most resource-intensive transport protocol (TCP) instead of fixing their stuff or choosing a more lightweight transport mechanism.

My argument (although theoretically valid) became moot a few months ago: Intel and Microsoft have demonstrated an iSCSI solution that can saturate a 10GE link and perform more than 1 million I/O operations per second. Another clear victory for the Moore’s Law.

Last November I was delighted to read the announcement describing how a module in CRS-1 was going to support CGN, NAT444, NAT64 and DS-Lite. It looked like a major vendor has finally decided it’s time to solve the IPv4-to-IPv6 transition problem.

However, I was not able to find anything beyond a few fancy videos, a white paper and a brochure. Can anyone shed more light on CGv6? Have you seen it running outside of PowerPoint? When can an IPv6-embracing Service Provider expect to see it on an ASR 1000?

I was invited to present my thoughts on NAT64 and DNS64 in the upcoming 3rd Slovenian IPv6 Summit (well, they still haven’t managed to create a bilingual site, so here's the same page from the perspective of Google Translate). While preparing for the presentation, I’ve greatly enjoyed reading the Framework for IPv4/IPv6 Translation IETF draft. I would highly recommend it; it’s rare to find such a concise and instructive document and it’s a mandatory reading if you want to understand the role of NAT in the IPv4-to-IPv6 transition.

The role of NAT64 in enterprise networks is described in the Enterprise IPv6 Deployment workshop.

Ever since I’ve figured out how to explain complex topics to bright engineers, I wanted to develop content (books, courses, documents) that explained (in this order):

• The Big Picture and WIIFM (What will the student gain by understanding and deploying something based on what I’m describing).
• How the technology we’re using actually works (remember: knowledge, not recipes) and finally
• How to configure, monitor and troubleshoot the actual boxes used to build the solution.

I’m positive you agree this approach makes perfect sense, and every now and then I’ve managed to get it right (for example, in the MPLS VPN books). Unfortunately, you’re often facing an uphill battle, as people want to focus on hands-on topics and hate to learn why things work the way they do instead of memorizing recipes like “Thou shalt not have more than 3 OSPF areas per router”.

The Wednesday's Building IPv6 Service Provider Core was a huge success (compared to the previous one); I had three times as many attendees from all over the world (map below) even though the topic was highly technical and pretty limited in scope. I can’t tell you how delighted I am that it went so well and I would like to thank (again) everyone who chimed in with improvement ideas.

Once you’ve spent a few hours trying to understand the implications of IPv6, you quickly realize that the only significant change is the increase in the address length. All the other goals that some people had been talking about were either forgotten or failed due to huge mismatch between idealistic view of the Internet IPv6 developers had 15 years ago and today’s reality. However, you still find mythical properties of IPv6 propagated across the Internet. Here are a few I’ve found; add your favorites in the comments.

IPv6 provides service/location separation. Total nonsense. The only mechanism used to find services is still DNS and it’s still used from the wrong position in the protocol stack.

Shivlu left an interesting comment to my IPv6 is not ready for residential deployment post. He wrote: “Still no customer is ready for IPv6. How do I convince them?” The unfortunate answer to this problem is: you can't, but they'll only hurt themselves. If they persist long enough, they’ll become obsolete.

The migration issues are just one of the topics covered in the Enterprise IPv6 Deployment workshop. You can attend an online version of the workshop or we can organize a dedicated event for your team.

The web content providers have long realized that their customers have too many choices. Zvezdan Martič, one of the participants in the last year’s Slovenian IPv6 summit roundtable succinctly explained this phenomenon: “nobody cares whether my web site can be viewed in Internet Explorer or Firefox; if I don’t support the major browsers, the customers will find one of my competitors that does.”

Daniel Miessler described an interesting application of the Workstation-as-a-Service (now you know what WAAS stands for ;) cloud service (formerly known as virtual desktop): enterprise network will have to protect their workstations against browser-based attacks and the best approach is to virtualize the browsers and isolate them in a sandbox behind a firewall.

Virtualization, virtual desktops and other security-related cloud services are described in my Next-generation IP Services workshop.