It seems that most people not having a vested interest in status quo agree the socket API is broken. After all, why should every single application ever written have to deal with the idiosyncrasies of two address families?

Not surprisingly, the browser vendors got sick and tired of waiting for a fixed API or a standardized session layer (nothing happened in the last two decades) and decided to implement happy eyeballs – a simple mechanism that creates two TCP sessions (one over IPv4, another one over IPv6) and uses whichever one works better.

Nicolas Michel left an interesting comment (quoting Cisco’s documentation) on my OSPF Route Selection Rules blog post:

… The OSPF route selection rule is that intra-area routes are preferred over inter-area routes, which are preferred over external routes. However, this rule should apply to routes learned via the same process …

Let’s see what’s going on behind the scenes.

You might not have to deploy IPv6 in your network tomorrow (if you’re an ISP I sincerely hope you do), but that’s no excuse for not getting prepared for the eventual inevitable deployment (Tom Hollingsworth has way more to say on this topic).

Don’t believe in the “inevitable” part? Maybe you should spend some time with people who were running SNA and IPX networks two decades ago and living in blissful IP denial.

One of the attendees of the ProgrammableFlow webinar sent me an interesting observation:

Though there is separate control plane and separate data plane, it appears that there is crossover from one to the other. Consider the scenario when flow tables are not programmed and so the packets will be punted by the ingress switch to PFC. The PFC will then forward these packets to the egress switch so that the initial packets are not dropped. So in some sense: we are seeing packet traversing the boundaries of typical data-plane and control-plane and vice-versa.

He’s absolutely right, and if the above description reminds you of fast and process switching you’re spot on. There really is nothing new under the sun.

There were numerous great presentations at last week’s MENOG 12 meeting. The best technical ones (from my perspective): BGP Traffic Engineering by Andy Davidson, problems WIMAX operators face in IPv6 world by Reza Mahmoudi and Regional Threat Profile by Dave Monnier (Team Cymru).

Once you get rid of spanning tree and associated kludges (not too hard in OpenFlow-based networks), BUM flooding becomes your biggest enemy. NEC’s engineers implemented some interesting features in the ProgrammableFlow switches and controllers: rate-limiting of unknown unicast frames, flooding control, and ARP snooping (if only they’d go for ARP proxy).

A heated debate on one of the IPv6 mailing lists (more about that later) contained a gem I simply have to share with you: The importance of IPv6 application testing from Apricot 2013. Enjoy!

One of my readers sent me an interesting question:

Are you aware of any studies looking at the effectiveness of IPv6 address allocation policies? I'm specifically interested in the affects of allocation policy on RIB/FIB sizes.

Well, we haven’t solved a single BGP-inflating problem with IPv6, so expect the IPv6 BGP table to be similar to IPv4 BGP table once IPv6 is widely deployed.

Sander Steffann, Iljitsch van Beijnum and Rick van Rein recently published an amazing IETF draft comparing IPv6-over-IPv4 tunneling mechanisms. If you’re even remotely interested in this topic, the draft is an absolute must-read (and if you want to know about other transitional mechanisms, check out this webinar).

OpenFlow is not exactly known for its quality-of-service features (hint: there are none), but as I described in the ProgrammableFlow Technical Deep Dive webinar NEC implemented numerous OpenFlow extensions in their edge switches and the ProgrammableFlow controller to give you a robust set of QoS features.