Unified Communications and SBCs in an IPv6 World
In writing last month’s paper on Federation Gateways, I started thinking about Session Border Controllers (SBCs) in general. A comment on that paper (from Hamid Nabavi) and an amusing and informative article about IPv6 posted around about the same time by my UCStrategies colleague, Dave Michels, caused me to consider SBCs in light of IPv6. Based on my (then) limited understanding of IPv6, it occurred to me that SBCs may not actually be needed in an IPv6 world. So I started to dig deeper into this and what I found was surprising.
A Brief History of IPv6
As I’m sure that you know, IPv6 is the next version of the Internet Protocol standard, intended primarily to address (pun intended) the exhaustion of the IPv4 address space. IPv6 was originally specified nearly 13 years ago and its impending deployment has been forecasted pretty much ever since. It turns out that the life of IPv4 was extended by the implementation of private networks operating behind Network Address Translators (NATs), but they were just a "Band-Aid solution" to a much bigger problem. The growth of the internet being what it is, the final blocks of IPv4 addresses were allocated by the Internet Assigned Numbers Authority (IANA) to the Regional Internet Registries (RIR) last February. The first RIR to deplete its address allocation was the Asia Pacific RIR (APNIC) in April. Given that:
- Internet endpoints such as tablets and smartphones are selling faster than free t-shirts;
- APNIC represents 53% of the world’s population but is allocated only 18% of the IPv4 address space:
- Yet this half of the world is the fastest developing and fastest to adopt internet technology (includes India and China).
…it’s a reasonable assumption that IPv6 deployment might actually be imminent. So what are the implications of IPv6 for UC?
IPv6 and UC
IPv6 extends the internet address space from 232 (4.2bn) addresses to 2128 (340 undecillion, or 340 with 36 zeros after it) addresses. According to Cisco, that is 100 IP addresses for every atom on the face of the Earth; so IPv6 should keep us going at least until the iPhone 5 is launched. Humor aside, this makes it possible for all digital media services, including UC, to be presented on as many "devices" as we have access to at any given moment (including cars, TVs, entertainment systems in aircraft seats, etc.). However, IPv6 has other benefits; many that are relevant to UC implementations:
- The elimination of the primary need for NATs (i.e. the size limitation of the public address space);
- An increase in privacy and security, by mandating Internet Protocol Security (IPsec);
- An elimination of the need for MAC addresses (another privacy issue);
- Multicasting is inherent in the design (thereby making conferencing implementation easier);
- An expansion of the IP packet size (MTU) to reduce packet fragmentation.
Many of these benefits are concerned with the way that UC traverses the boundary between the enterprise network and the public network. This is normally the domain of the SBC so, at face value, it would seem that the SBC business is about to be disrupted.
IPv6 and SBCs
The primary role of SBCs in a UC implementation is threefold:
- Facilitating the transmission of UC signaling and media through NATs and firewalls;
- Maintaining network and communications security and privacy;
- Intermediating incompatible protocols and media, including addressing SIP over UDP packet fragmentation (as a B2BUA, SBCs are compelled to do this).
Comparing these to the IPv6 benefits above, the main features of the SBC appear to be at least partially invalidated by IPv6. However, the diminishment of the role of the SBC by IPv6 assumes several things:
- A global "flash-cut" from IPv4 to IPv6, which we know isn’t going to happen;
- The elimination of the DMZ, NATs and internal topology hiding that currently provide defense against internet-borne malfeasance;
- The implementation of end-to-end authentication and encryption between all networked devices:
- This would encompass all clients and servers that are within the DMZ and which would traverse the DMZ (e.g. UC clients);
- This is something we are not even seeing now in all UC implementations and deployments (either by design or by policy) or in SIP Trunking (see my previous paper on this).
Therefore it is reasonable to assume that the SBC will survive at the very least until both the ISP and the enterprise have each transitioned to IPv6, and maybe longer. There may (or may not) be an additional role for the SBC in IPv4-IPv6 conversion, particularly if the Federation Gateway role becomes a reality (i.e. to make transparent the timing of the conversion to IPv6 of your federation partners).
Implications for the UC vendor and the UC customer
As you can tell, I don’t have all (or even any) of the answers: this paper is really just a list of questions. However, these are probably questions that readers are asking themselves. Therefore, in keeping with the mission of my consulting and analysis firm, I am setting myself the task of providing some IPv6 UC Insights. I intend to conduct a deeper investigation into the implications for IPv6 for UC and to conduct a survey of UC vendors, including SBC vendors, on their plans for IPv6 and the role that their products play in an IPv6 world. The timeline for publication is mid-late Q4 ’11.
If you are interested in seeing a copy of this survey, have suggestions or comments, or would like to participate, please contact russell@ucinsights.com.