Category: IPv6

One of the topics I discussed in the IPv6 High Availability webinar is the problem of dual-stack deployments – what do you do when the end-to-end path for one of the protocol stacks breaks down. Happy eyeballs is one of the solutions, as is IPv6-only data center (Facebook is moving in that direction really fast). For more details, watch the short End-to-End High Availability in Dual Stack Networks video available with Free Subscription.

One of my readers was reading the Preparing an IPv6 Addressing Plan document on RIPE web site, and found that the document proposes two approaches to IPv6 addressing: encode location in high-order bits and subnet type in low-order bits (the traditional approach) or encode subnet type in high-order bits and location in low-order bits (totally counter intuitive to most networking engineers). His obvious question was: “Is anyone using type-first addressing in production network?”

Terastream project seems to be using service-first format; if you’re doing something similar, please leave a comment!

The video of my Troopers 15 IPv6 Microsegmentation presentation has been published on YouTube. As with the Automating Network Security video, it’s hard to read the slides; you might want to look at the slide deck on my public content web site.

You’ll find more about this topic, including tested Cisco IOS configurations, in IPv6 Microsegmentation webinar.

An interesting message appeared on v6ops mailing list a few days ago: the first interconnect between independent IPv6 implementations was established 20 years ago. No wonder some youngsters who don't know any better treat this venerable protocol like a modem and ignore it in favor of IPv4 ;)

I was talking and writing about IPv6 myths for years, but like any good myth they tend to be pretty robust. Unfortunately, as I explained in the IPv6 Myths and Reality part of IPv6 High Availability Strategies webinar, the reality seems pretty bleak: all we got are longer addresses, half-baked protocols, unsolved challenges, and heaps of confusion.

The IPv6 Security Summit at the Troopers conference always has a few awesome IPv6 presentations (many people claim Troopers is the conference to attend if you’re serious about IPv6), and this year was no exception. A day after the MLD bashing, Enno Rey delivered a great in-depth presentation on DHCPv6 features and shortcomings.

It seems the DHCPv6 intricacies presented in that talk were too much for some of the attendees – that afternoon I accidentally stumbled upon a visibly distressed gentleman who started our chat with “How could anyone expect us to deploy IPv6 in a production environment?”

Multicast Listener Discovery (MLD) protocol is well hidden deep in the bowels of IPv6 protocol stack and most of us tend to gloss over it when we discuss IPv6 neighbor discovery process… until MLD raises its ugly head to bite an unsuspecting network administrator.

The problems with MLD are not new (and I wrote exhaustively about them a while ago), but it’s always nice to see other people raise awareness of broken IPv6 features like Enno Rey and his security team did during the IPv6 Security Summit (part of Troopers 15 conference).

Last spring I ran an IPv6 High Availability webinar which started (not surprisingly) with a simple question: “which network components affect availability in IPv6 world, and how is a dual-stack or an IPv6-only environment different from what we had in the IPv4 world?”

This part of the webinar is now available with Free Subscription. Enjoy the video, and don't forget to explore other IPv6 resources on ipSpace net.

In one of the discussions on v6ops mailing list Matthew Petach wrote:

The probability of us figuring out how to scale the routing table to handle 40 billion prefixes is orders of magnitude more likely than solving the headaches associated with dynamic host renumbering. That ship has done gone and sailed, hit the proverbial iceberg, and is gathering barnacles at the bottom of the ocean.

Is it really that bad? Is simple renumbering in IPv6 world just another myth? It depends.

The edited videos for my Enterprise IPv6 webinars have been published on my.ipspace.net. Enjoy!

More than a year ago I wrote a response to a comment Pascal wrote on my Predicting the IPv6 BGP table size blog post. I recently rediscovered it and figured out that it’s (unfortunately) as relevant as it was almost 18 months ago.

Other people have realized we have this problem in the meantime, and are still being told to stop yammering because the problem is not real. Let’s see what happens in a few years.

A few days ago Garrett Wollman published his exasperating experience running IPv6 on large L2 subnets with Juniper Ex4200 switches, concluding that “… much in IPv6 design and implementation has been botched by protocol designers and vendors …” (some of us would forcefully agree) making IPv6 “…simply unsafe to run on a production network…”

The resulting debate on Hacker News is quite interesting (and Andrew Yourtchenko is trying hard to keep it close to facts) and definitely worth reading… but is ND/MLD really as broken as some people claim it is?

One of my readers sent me an interesting challenge: they’re deploying a new DMVPN WAN, and as they cannot expect all locations to have native (non-NAT) IPv4 access, they plan to build the new DMVPN over IPv6. He was wondering whether it would work.

Apart from “you’re definitely going in the right direction” all I could tell him was “looking at the documentation I couldn’t see why it wouldn’t work” Has anyone deployed DMVPN over IPv6 in a production network? Any hiccups? Please share your experience in the comments. Thank you!

After the excellent IPv6 security presentation Eric Vyncke had @ 9th Slovenian IPv6 summit someone asked me: “Why is IPv6 first-hop security so complex? It looks like the developers of IPv6 protocol stack tried to make users anonymous and made everyone’s life complex while doing that.”

Well, he was totally surprised by my answer: “The real reason IPv6 first-hop security is so complex is the total mess we made of L2/L3 boundary.”

A while ago Paul Stewart wrote a fantastic blog post listing the potential business benefits of SDN (as promoted by SDN evangelists and SDN-washing vendors).

Here’s his list: