Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

Start now!
back to overview

Does Your Favorite Startup Support IPv6?

Whenever you talk to a new startup evaluating whether you’d consider including their products in your network, don’t forget to ask them a fundamental question: “does your product support IPv6?

If they reply “Nobody has ever asked for it”, it’s time to turn around and run away.

There are a few reasons for this recommendation.

First, if none of their customers asked about imminent technology like IPv6, it means that their customers are not forward-looking bunch but people who believe technology problems can be solved with glitzy UIs, unicorn dust and magic (see also RFC 1925 section 2.11 and this famous quote misattributed to Einstein). Do you really want to be in that crowd?

I apologize for breaking the news to some overly innocent people, but there really is no magic and no Bandwidth Fairy.

There might be other excuses, usually along the lines of “we know all about IPv6, but it’s not high on our priority list because whatever,” in which case you might want to do a deep dive into the architecture of their solution to understand whether adding IPv6 support is a trivial task (because the architecture of the product supports multiple address families) or a total overhaul of the product (because the product architects and developers still live in single-protocol world).

Alain Fiocco who’s been working on IPv6 for decades made an interesting statement in a Packet Pushers podcast: if you include IPv6 in your product from day 1, it increases your development costs by less than 10%. If you have to reopen the hood and retrofit IPv6 into existing code, it costs way more.

Also, there’s no guarantee that a product you’ve decided to buy eventually gets IPv6 support regardless of what the vendor promised you when you were buying it, because the overhaul might be too expensive. Some well-known load balancing and DPI product immediately come to mind ;)

The only excuse I would accept is “our product works with IPv6, and we can demonstrate it, but we’re doing no testing on that part of the code”, because that shows that they do understand the multi-protocol nature of today’s Internet. However, even that is good enough only for products with software-only data plane. The moment forwarding hardware gets involved, you have to be way more careful.

5 comments:

  1. "We still have time to implement IPv6" and "Our provider does not support IPv6" was what I got when I asked for IPv6 for two popular websites (see http://blog.quux.de/?p=1893 and http://blog.quux.de/?p=1898).

    Looks like many of the big cloud providers have no or only limited IPv6 support.IIRC there was a longer discussion about aws and IPv6 on the nanog mailing list earlier this year.

    ReplyDelete
    Replies
    1. With CloudFlare, Akamai and a number of other CDN providers offering 6-to-4 translation service, these excuses become totally lame.

      As for AWS, they started offering IPv6 on the outside years ago. Getting IPv6 running on the inside will take quite a while, as they do routing in their custom virtual switch.

      Delete
    2. This comment has been removed by the author.

      Delete
  2. Is Cisco Meraki still considered a Startup? ;-)
    But for sure, they will also suport IPv6 eventually .. (hopefully)

    ReplyDelete
    Replies
    1. Oh no, not again... did anyone take a look at the calendar lately?

      SCE, ACE, vASA, IronPort, Nexus 5500, Nexus 1000V, ACI... will it never end? At least they fixed some of these products (and killed a few others).

      Delete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Sidebar