Sunday, December 23, 2012

P2P networking during the IPv6 transition and beyond

After getting some fresh air a couple of weeks ago, i started to think about what kind of internet connection types are to be expected during the IPv4-to-IPv6 transition period (based on this year's developments and apparent trends in IPv6 and IPv4 CGN deployments), about how long this transition period might be, and then i pondered if/how can this transition period be accommodated by a pure P2P network topology. This post is about what i came up with.

First, the time frame: i divided the transition period into a first stage 2012 -> 2020 during which the adoption of IPv6 will increase to reach some 40% market share, while in parallel most IPv6 deployments will be accompanied by either a legacy routable IPv4 address or by a new private IPv4 address delivered by the ISP via CGN (note: it is possible, even likely, that mobile IPv6 internet connectivity will lag the cable IPv6 deployments, such that only private IPv4 CGN-based connectivity will be provided on mobile networks for quite a few years to come); then, a second stage of the IPv6 transition i guesstimated it to span the 2020 -> 2030 time frame, during which IPv6 will incrementally become the norm, while routable IPv4 will most likely almost disappear, and also private CGN-based IPv4 addresses might be phased out.

The connection types for the two-stage transition scenario mentioned above are illustrated below, with guesstimated percentages (market share) for the three time points 2012, 2020, 2030 included in parenthesis next to each connection type:

  • the top half of the diagram above "IPv4 host" illustrates the types of connections that will be available for IPv4-only hosts during the transition period
  • the bottom half of the diagram "IPv4+IPv6 dual stack host" illustrates the types of connection that will be available for dual-stack hosts (i.e. for the hosts that will be connected to the internet via both an IPv4-type connection and an IPv6-type connection)
  • the total of ~15% IPv4 CGN-based connections listed for 2012 in the diagram above mostly account for 3G/4G mobile connections (these connections almost never provide a Public IPv4 to the end user)

In order to analyze how two given hosts can establish a P2P connection given the transition scenario described in the diagram above, we will consider all the possible variants for a pair of hosts with one host being the connection initiator and the other host being the responder. Based on this convention, the diagrams that follow in this post will specify how a P2P connection can be made depending on the type of connection that each of the two hosts has to the internet.

To make things easier to understand, let us start with an example diagram that illustrates how an IPv4-only host with a public IPv4 address initiates a connection to another IPv4-only host which sits behind an Endpoint-Independent Mapping NAT device: specifically, the diagram below shows that a direct link can be established between the initiator and the responder (this link is illustrated in the diagram by the blue arrow), i.e. in this specific example the P2P connection does not need to pass through a relaying peer, and thus no assistance is needed from other peers for establishing the connection:

And now let us look at all the possible P2P connection variants, grouped into "connection classes" diagrams.

For starters, the next diagram shows the types of internet connections that the initiator and responder must have in order for them to be able to establish a direct IPv4 P2P connection (i.e. without requiring a relaying peer):

  • for example, the last connection type in the diagram above (counting on the initiator side) links an initiator peer with a Large Port Set CGN-based [IPv4] connection to a responding peer that has a Public IPv4 address (or UPnP)

A second class of IPv4 connections is illustrated in the diagram below, where the types of [IPv4] connections that the initiator and responder have to the internet require the assistance of a third peer for relaying their communications, with said third-party relaying peer being connected to the internet via an Endpoint-Independent Mapping [IPv4] NAT router.
  • note: the EIM NAT44 relaying peer in the diagram below could also be a Public IPv4 (or UPnP) peer, but Public IPv4 connections are scarce and becoming scarcer by the day (while EIM NAT44 connections are plentiful), such that the Public IPv4 peers have been reserved (in this analysis) for relaying other kinds of IPv4 P2P connections that cannot use EIM NAT44-based relays (the P2P connections which strictly require a Public IPv4 relay are discussed in the next paragraph)
  • for example, the last connection type in the diagram above (counting on the initiator side) links an initiator peer with a Small Port Set CGN-based [IPv4] connection to a responding peer that sits behind an Endpoint-Dependent Mapping [IPv4] NAT with incremental port allocation

The next class of IPv4 connections shown in the diagram below also requires a third peer for relaying the communication between the initiating and responding peers, but in these cases said third-party relaying peer has to have a Public IPv4 (or UPnP) connection to the internet:

  • for example, the first connection type in the diagram above (counting on the initiator side) links an initiator peer sitting behind an Endpoint-Independent [IPv4] NAT with a responding peer that sits behind an Endpoint-Dependent Mapping [IPv4] NAT with random port allocation

Let us now look at the situations where one peer is IPv4-only and the other peer is dual-stack: in this case, a P2P connection between said types of peers will require an IPv4+IPv6 dual-stack relaying peer, where said relaying peer will not only relay the data between the initiator and the responder, but it will also perform a protocol translation:

  • the red dashed lines: if one (or both) of the peers illustrated in the diagram above as IPv4+IPv6 dual-stack does not actually have IPv6 connectivity, then connecting such two peers will require the assistance of a Public IP (or UPnP) relaying peer (represented by the red dashed line)

The last class of possible connections is illustrated in the diagram below, where both peers are dual stack: in this case a direct P2P link can be established over IPv6 between the two peers, without the assistance of a relaying peer:

  • the dashed lines: if one (or both) of the peers illustrated in the diagram above as IPv4+IPv6 dual-stack does not actually have IPv6 connectivity, then, depending on the kinds of IPv4 connections the two peers have to the internet, the connection between such two peers can be established either as a direct IPv4 P2P connection (this is the case of the blue dashed line above, when both peers are connected via an Endpoint-Independent CGN), or the connection will require the assistance of a Public IP (or UPnP) relaying peer (these situations are represented by the red dashed lines) or an Endpoint-Independent NAT relaying peer (these situations are represented by the green dashed lines)
  • as it is obvious from the diagram above, once the transition to IPv6 will be completed, all P2P connections will be feasible as direct IPv6 connections, i.e. they will not require a third-party peer for relaying the P2P communication.

Finally, a couple of important remarks on the dashed-lines connections illustrated in the diagrams above:
  1. the dashed lines connections are to be used only in those situations when the solid line connections cannot be used; for example, a quite plausible situation when the dashed lines connections might have to be used is in the case of mobile 3G/4G connections which may only provide IPv4 CGN-based connectivity for a few more years to come (before finally adding IPv6 support)
  2. the biggest vulnerability of the P2P topology presented in this post are the *red* dashed lines connections in the last two diagrams because they use a Public IPv4 (or UPnP) relaying peer, and such peers are an already scarce resource in today's internet topology, only to become scarcer during the IPv4-to-IPv6 transition; specifically, one can think of a pessimistic scenario where 3G/4G mobile connections will reach some 70% market share (sometime during 2012 -> 2020) while only implementing IPv4 CGN-based connectivity (i.e. without IPv6), and by that time the availability of Public IPv4 peers may well be reduced to some 5% (or less) market share: in this case, the red dashed lines connection in the two diagrams above may well account for some 50% of all the possible P2P connection routes, and with only 5% relays available in the network there will be about one Public IPv4 relaying peer online for each 10+ P2P live connections that will require such a relay, which will result in such a heavy strain on the Public IPv4 relays that said relays might have to throttle their relaying speed and only allow for low-traffic relaying services during periods of network congestion (e.g. they will probably still be able to relay text messaging, slow-rate file transfer, and maybe voice, but they will most likely have to degrade/deny their relaying service for video streaming, desktop sharing, or other high-traffic services)

In conclusion, now that i'm done with this deluge of diagrams and geeky explanations, here's my 2 cents in a nutshell: should the IPv6 and CGN deployments stay the right course, and, sure enough, if i'm not missing some show-stopper somethin' somethin', the point to take home from this post is that it currently seems the tide has turned from exactly one year ago and P2P networking now seems feasible for both during, and after, the IPv4-to-IPv6 transition period, with the caveat that some serious challenges still exist, mostly related to how IPv6 and CGNs will be deployed on the 3G/4G mobile networks, and i don't yet have sufficient data to guesstimate how serious said challenges are.

In other news:
Qt5 is out, with my stalking here:

Wednesday, December 5, 2012

IPv6 picking up steam, and it's apparently done right

I've been touring the net for the past week to check out what the current state of affairs is with IPv6 implementations and deployments to the end users, and what i found is very encouraging, at least for now: namely, all the major ISPs i've checked on the net (, Telefonica, Deutsche Telecom, Swisscom, Comcast, AT&T, TWC, DoCoMo, and even my home country's RCS-RDS network) seem to provide end users with at least a proper, P2P-friendly /64 address block (instead of one single /128 address, and then leave the users to cope with it by using all sorts of non-standardized NAT66 boxes).

Since the two main reasons for putting this project on hold one year ago were the unknowns related to IPv6 deployment and the uncertainties plaguing the future of Qt, and since significant progress is apparently being made in the right direction on both of these issues, at this point in time i can see at least some reasons for renewed hope on this project's future.

Some of the IPv6 deployment links i've checked:
...and some live stats by ISPs here:
So what i'll probably do next is write a small IPv6 tester application to effectively check the IPv6 deployments as they are in the real world; once i'll do this i'll post the results.

I haven't been able to find any reliable stats on 3G/4G mobile IPv6 deployment trends just yet, but i'll keep looking. And the same holds for mobile CGN-based IPv4 connections: this also needs some further investigation.

Thursday, September 20, 2012

Qt resurrected, support planed for Android and iOS

This might be really big:
Helsinki, Finland and Santa Clara, US - September 18 2012, Digia (NASDAQ OMX Helsinki: DIG1V) today announced that it has completed the acquisition of the Qt software technologies and Qt business.
Qt already runs on leading desktop, embedded and real-time operating systems, as well as on a number of mobile platforms. Digia has initiated projects to deliver full support for Android and iOS mobile and tablet operating systems within Qt and will present the product roadmap and strategy later in the fall.
All significant existing online Qt information has been transferred to, which, along with, is now the main information-sharing site for Qt.
Now add to the above the cut-them-chains-and-break-free move of Qt5 to QPA (a nice tour at Dr. Dobb's here), and Qt might just have set itself on course for becoming a reliable and future-proof platform. But then again, there's still allot of work to do to make Qt truly platform agnostic - namely, QPA must become a full platform abstraction layer instead of focusing only on the display server, and there's no clearly stated plan in this direction on Qt's website, so only time will tell...

I can't help wondering if Digia's management really understands what QPA's potential implications are for their business (especially if it is to grow into a complete abstraction layer, multimedia included and all), so until i see QPA fully integrated (and properly documented) in the LGPL-ed version of Qt5 i'll just call myself "cautiously optimistic" on this rather extreme openness move...

Thursday, June 21, 2012

IPv6 lauched: "this time it's for real"

Under the slogan "this time it is for real", IPv6 was officially launched on 06.06.2012. What will follow in the next couple of years, namely the way in which the world's major ISPs will deploy IPv6 on terrestrial and mobile networks to the end customer, will determine the future fate of the internet: to P2P or not to P2P.

At this point in time there are some encouraging signs in that ISPs engaged in the IPv6 transition seem to follow the new standard's guideline of providing /64 (or better) prefixes to the landline users and (at least) a proper /128 address to mobile devices, but nothing can be thought of as cast in iron at this early stage of deployment; only time will tell.

One very encouraging thing is that the IETF seems to manage to control the open-standards game, and the "IPv6 ready" logo is an extraordinarily powerful tool for steering CPE manufacturers to play the game properly (i.e. plain simple prefix delegation, without one-to-many NAT66 improvisations on their devices).

Maybe there still is hope.