IPv6 is often called a “complex protocol”, not least by myself (for example in my keynote to the IPv6 Security Summit 2014). In this post I want to have a quick look at three questions:
– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?
I’d like to start with some clarifications and a definition. First of all: when I discuss IPv6 “as a protocol”, this actually means “the IPv6 procotol family” incl. those helper protocols needed to support (“core”) IPv6 in performing properly in most networks, like ICMPv6 and MLD.
Then, of course, we have to define the term “complexity”, which is a difficult task in itself. [MITCHELL2009] gives an overview of several potential (definition) approaches in a dedicated chapter and the same undertaking is performed – in quite different ways – by most of the authors of individual contributions to [PELITI1988].
For this post I will use the definition provided by the Random House Dictionary which lists “complex” as:
1. composed of many interconnected parts.
2. characterized by a very complicated or involved arrangement of parts, units, etc.
3. so complicated or intricate as to be hard to understand or deal with.
So let’s focus on IPv6 and go through these properties:
a) the IPv6 protocol family is composed of several protocols (“core IPv6” as of RFC2460 et.al., ND, MLD, additional ICMPv6-based functions like redirects and potentially even others [DHCPv6]), so I think we can state that this attribute applies. Many of those use multicast transport which inherently is more complex than broadcast based transmission. Add extension headers to the mix (btw: Julian Bangert discussed extension headers and parsing complexity in his talk at the 2015 IPv6 Sec Summit).
IPv4 mostly has ARP and a much lighter variant of ICMP so I tend to say that IPv4 was “less complex” with regard to this attribute.
b) these protocols interact in various complicated ways, both on the specification level (there’s a reason why RFC4861 has 95 pages…) and in real-life networks (see our discussion of the ND MLD interaction and have a look at this mess). Furthermore the helper protocols have taken over duties previously unknown (or, say: “unused”. I’m aware of RFC 1256…) in IPv4 networks, that is mainly “provisioning of configuration information to nodes” (by means of router advertisements which, btw, have a huge number of options and flags themselves). Which leads to even more interactions.
So this one clearly applies.
IPv4 had less “helper” protocols which in turn had less functionality and hence less interactions. It was certainly – much – less “complex” from the angle of this attribute.
c) the 3rd attribute (“so complicated … to be hard to understand”) can only be discussed from a personal standpoint. While I’ve been involved with IPv6 from many perspectives (teaching workshops, doing research in the lab, performing both planning & design projects and practical implementation & troubleshooting) for quite some years now, I can tell you that I still regularly learn something new or stumble across situations where I think I had understood something just to find out that things are different. For example I still struggle to apply the rules from RFC6724 on address selection in some cases which end up with systems doing sth else than I had expected. So from my perspective this one applies, too.
As for the comparison with IPv4: well, maybe because I was much younger or maybe because memories get blurred over time (usually they become less unpleasant ;-), I’d say in hindsight that IPv4 was easier to learn and I needed to read (way) less RFCs and/or perform hands-on tasks to understand the core parts of it.
===
Now, let’s discuss the complexity of “IPv6 networks” (as whole entities assembled of nodes running the protocol in question):
a) “composed of many interconnected parts” – looking at the horizon of the (bingo!) “Internet of Things” there _will_ be many many interconnected parts in future IPv6 based networks. And there _will_ be more nodes running IPv6 than have been/are running IPv4. I’d say: this attribute applies.
b) “complicated arrangements of parts” – again, the nature of networks running IPv6 that we’ll see in the future will probably include some “complicated arrangements of parts” ;-).
I tend to say: attribute (will) applies.
c) “so complicated … to be hard to understand or deal with”. Well, we shall see, right?
Let me just state that [CASTI1979] mentions that “complexity involves notions of nonintuitive system behavior, patterns of connection among subsystems such that prediction of system behavior is difficult without substantial analysis or computation, decision-making structures that make the effects of individual choices difficult to evaluate” (p. 97). I leave this just here ;-).
Last but not least let me point your attention to Dan Geer’s great keynote (“Driven by Data“) at the recent LANGSEC workshop (organized by my friend Sergey Bratus) in the course of the IEEE S&P symposium.
Dan uses “complex” and “complexity” many times and – if my understanding is correct – does this in a way similar to the one applied above.
I’m fully fully aware that the above discussion only touched the surface of the inherent issues and the complex topic of complexity itself. Still I hope to contribute to a better understanding of the term and why certain protocols are “complex” (and which dangers this might pose. btw: it’s always a good idea to (re)-read RFC 3439). I’m happy to receive feedback/comments of any type.
Best
Enno
References:
[CASTI1979]: Casti, John L., Connectivity, Complexity, and Catastrophe in Large-Scale Systems, Chichester (John Wiley & Sons), 1979. online here.
[MITCHELL2009]: Mitchell, Melanie, Complexity: A Guided Tour, New York (Oxford University Press) 2009.
[PELITI1988]: Peliti, Luca & Vulpiani, Angelo [Eds.], Measures of Complexity. Proceedings of the Conference, Held in Rome, September 30–October 2, 1987, Heidelberg (Springer) 1988.