Category: IPv6

Continuing the IPv6 address selection discussion we have a few days ago, Luka Manojlovič sent me a seemingly workable proposal:

I think we were discussing a borderline problem. In a server environment there won’t be any SLAAC, and we could turn off DHCPv6 client on servers with fixed IP addresses.

Sounds great, but as always, the reality tends to be a bit harsher.

The proponents of microsegmentation solutions would love you to believe that it takes no more than somewhat-stateful packet filters sitting in front of the VMs to get rid of traditional subnets. As I explained in my IPv6 Microsegmentation talk (links below), you need more if you want to have machines from multiple security domains sitting in the same subnet – from RA guard to DHCPv6 and ND inspection.

The breadth of address allocation options available in IPv6 world confuses many engineers thoroughly fluent in IPv4, but it also gives operating system developers way too many options… and it turns out that different operating systems behave way differently when faced with the same environment.

2016-01-21: In the meantime, Luka got further details on Windows behavior, and Enno Rey provided a few additional links.

If you’re a host running on an IPv6-only network, you might want to detect the IPv6 prefix used for NAT64 (for example, to transform IPv4 literals a clueless idiot embedded into a URL into IPv6 addresses).

Apple has a wonderful developer-focused page describing NAT64 and DNS64, including the way they synthesize IPv6 addresses from IPv4 literals. You (RFC 6919) MUST read it.

In an amazing turn of events, at least one IETF working group recognized we have serious problems with IPv6 multihoming. According to the email Fred Baker sent to a number of relevant IETF working groups:

PI multihoming demonstrably works, but PA multihoming when the upstreams implement BCP 38 filtering requires the deployment of some form of egress routing - source/destination routing in which the traffic using a stated PA source prefix and directed to a remote destination is routed to the provider that allocated the prefix. The IETF currently has no such recommendation, or consensus that it should have.

Here are a few really old blog posts just in case you don’t know what I’m talking about (and make sure you read the comments as well):

While researching for another blog post, I stumbled upon this speech by Winston Churchill:

When the situation was manageable it was neglected, and now that it is thoroughly out of hand we apply too late the remedies which then might have effected a cure. There is nothing new in the story. It is as old as the Sibylline Books. It falls into that long, dismal catalogue of the fruitlessness of experience and the confirmed unteachability of mankind. Want of foresight, unwillingness to act when action would be simple and effective, lack of clear thinking, confusion of counsel until the emergency comes, until self-preservation strikes its jarring gong -these are the features which constitute the endless repetition of history.

Obviously mr. Churchill wasn't talking about IPv6 but about way more serious matters… but it's also obvious he was right abut the unteachability of mankind.

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.

The OSCON keynote by Simon Wardley explains a number of things, including (lack of) enterprise IPv6 adoption. Enjoy!

35 years ago, mainframes, single-protocol networks (be it SNA or DECnet), and centralized architectures that would make hard-core SDN evangelists gloat with unbridled pride were all the rage. If you’re old enough to remember IBM SNA, you know what I’m talking about.

A few years later, everything changed.

Like all other ipSpace.net webinars, the IPv6 Microsegmentation webinar starts with a brief description of the problem we’re trying to solve: the IPv6 first-hop security challenges.

For an overview of this problem, watch this free video from the IPv6 microsegmentation webinar, for more details, watch the IPv6 Security webinar.

While some people lament the lack of IPv6 business case, others are busy rolling it out – you (RFC 2119) SHOULD check out the Status of Swisscom’s IPv6 Activities presentation from recent Swiss IPv6 summit.

Geoff Huston published an interesting number-crunching exercise in his latest IPv6-focused blog post: 8% of the value of the global Internet (GDP-adjusted number of eyeballs) is already on IPv6, and a third of the top-30 providers (which control 43% of the Internet value) have deployed large-scale IPv6.

The message is clear: The big players have moved on. Who cares about the long tail?

Hank left a lovely comment on my Rearchitecting L3-Only Networks blog post:

What you describe is literally intra-area routing in CLNS.

He’s absolutely right (and I admitted as much during my IPv6 Microsegmentation presentations @ Troopers 15).

Great news for everyone trying to deploy IPv6 in OpenStack: the Kilo release has full support for IPv6 in the tenant networks, including SLAAC, stateless and stateful DHCPv6. For more details, read an extensive blog post by Shannon McFarland.

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.