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.

Arnold sent me an excellent question yesterday; he bought my Deploying Zone-Based Firewalls book, but found no sample configurations using IPSec VPN. I was able to find a few sample configurations on CCO, but none of them included the self zone. The truly interesting bit of the puzzle is the traffic being received or sent by the router (everything else is self-explanatory if you’ve read my book), so those configurations are not of great help.

Realizing that this is a bigger can of worms than I’ve expected, I immediately fixed the slides in my Choose the Optimal VPN Service webinar, which now includes the security models for GRE, VTI and DMVPN-based VPN services.

A few days ago I’ve received a cryptic e-mail with exactly this content: “I am having a issue "static routes not flushed when next hop is unreachable" please advice.” I suspected that the sender actually wanted to ask me what to do if a static route pointing to an IP next-hop does not disappear when the next hop becomes unreachable and told him to adjust the ip route static adjust-time parameter while monitoring the CPU usage.

In another Ask the Expert topic, I’m answering the question on expected Wimax deployment scenarios. Although I personally believe it’s a better technology than LTE (and obviously I cannot comment on the RAN part of either), I don’t expect existing mobile operators to pick it up, as they’ve thrown too much money into the GSM/HSCSD/GPRS/EDGE/UMTS/HSDPA/HSUPA neverending story.

One would hope that the IPv6 myths are slowly fading away as more people get exposed to IPv6 ... but if you like them, don’t worry; they are constantly being recycled. The IPv6: Why Bother? article published by InformIT is a perfect example:

With IPv6, there are enough addresses now that every country or major network can be assigned a large range. It can then assign subranges within that to networks that it connects to, and so on. This hierarchical assignment (in theory, at least) simplifies routing decisions.

The "You can't secure the cloud" article published by Hoff on Rational Survivability discusses whether you can make the cloud solutions as secure as enterprise (walled garden) ones. Here's a great summary:

Yes, it’s true. It’s absolutely possible to engineer solutions across most cloud services today that meet or exceed the security provided within the walled gardens of your enterprise today.

Every now and then an incident reminds us how vulnerable BGP is. Very few of these incidents are intentional (the Pakistan vs. YouTube is a rare exception) and few of them are propagated far enough to matter on a global scale (bugs in BGP implementations are scarier). Most of these incidents could be prevented with either Secure BGP or Secure Origin BGP but it looks like they will not be implemented any time soon.

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

Every so often I stumble across a blog post (or receive an e-mail) complaining how hard it is to learn the material needed to pass a certification exam. That’s definitely true if you try the memorization approach to networking: trying to cram as many facts as possible into your grey matter. However, it’s impossible to make any reasonable progress that way; to move forward, you have to handle networking like you would math or physics: having a firm basic foundation, you slowly expand it, all the time trying to fit the new concepts into a coherent model (let’s call it “the big picture”).