The internet as we (don't) know it

In an older post (dec. 2012) i described how a connection can be established between two IPv4 hosts sitting behind various types of NAT/CGN connections, based on whether said NAT/CGNs are UPnP-enabled, or they are BEHAVE-compliant, or they are [a variation of] BEHAVE non-compliant, with the hidden assumption that the CGNs follow the IETF recommendation and are set up with "paired" address pooling.

Well, fast forward four years, and a new study (sept. 2016) on the state of IPv4 CGNs apparently proves my hidden assumption wrong: specifically, despite IETF's strong recommendation for setting up "paired" address pooling on CGNs, many (~20%) internet service providers, including high-profile ISPs spanning all geographical regions, seem to ignore this recommendation and they choose to set up "arbitrary" address pooling on their CGN gateways (see "NAT pooling behavior" at page 11 in said study).

The problem with arbitrary address pooling is that it significantly impairs on the ability to connect two hosts when one+ host is sitting behind an arbitrary address pooling CGN: specifically, in this situation not only is a relaying host (peer) needed, but said relay must have a public IPv4 address (which in practice means it has to sit behind a single layer of UPnP-enabled NAT), and this type of IPv4 internet connection is already extremely scarce (estimates for 2016 vary between 1% and 5%) and it will only get scarcer by the day.

From the P2P OS perspective, the numbers revealed by the above-mentioned study translate into having a much larger number of hosts that will require a public IP (or a single-layer UPnP-enabled NAT) relaying host than previously estimated; in fact, if indeed ~20%+ of the CGNs that will be deployed in the future will have arbitrary address pooling then my current P2P OS networking scheme will simply not be able to accommodate most of such hosts (i.e. hosts sitting behind arbitrary address pooling CGNs).

In conclusion, although the current IPv4 technology (including the CGN technology) allows for an IPv4 internet which can support a self-sustaining p2p network, many ISPs, including high-profile ISPs, chose to go against the IETF recommendations, and by doing so they put in severe jeopardy the future of any and all IPv4-based p2p networks. In this context, a new analysis is now required to see if/how the current trend of deploying arbitrary address pooling CNGs can be accommodated by P2P OS via a [new type of] connection that can handle arbitrary address pooling CGNs.

IPv6 adoption in exponential growth stage

This is the third year in a row that sees IPv6 adoption growing exponentially, with a factor a bit over 2:1 year-on-year (2011 -> 2012 -> 2013). Since we're in the early deployment stage, this trend can be expected to continue for at least several years (and maybe with an even larger factor), such that by the end of 2015 a 10% IPv6 penetration is most likely a conservative estimation.

 

(source: http://www.google.com/ipv6/statistics.html)

The IPv6 penetration, even in low numbers, is important for this project because IPv6 can be used to do the heavy lifting in the routing ring, such that the more IPv6 connections are deployed, the less the bandwith strain on the routing ring peers.

A milestone year in the standardization of computing

The time for staring work on the production-quality P2P OS is getting nearer by the day, so i thought it's high-time to look around a bit and try to get a clear picture of what tools and technologies are out there for building true cross-platform applications nowadays, and much to my delight here's what i found:

1. we now have native threads built right into C++11, so there's no need for third-party libs (with God knows what kinds of portability problems each) any more
2. since the days of HTML4 already, one could build a full-featured GUI right onto a web page and have it rendered in any compliant browser (Wt is a pretty neat showcase for what can be done this way), except only for the multimedia features which were not included in the HTML4 standard; now the W3C is making really quick progress towards baking exactly these capabilities into the HTML5 standard (via the free VP8 format), plus device I/O and persistent storage (all of theses especially driven by WebRTC's needs), such that once work will have been completed on these issues a standard HTML5 web page will be able to deliver a full desktop-like experience right inside a web browser (including smooth 2D graphics editing and animation via SVG and high-quality 3D effects via WebGL)
3. last but not least, Qt is making steady progress towards becoming a usable C++ cross-platform development tool not only for all the major desktop OSes Win/Mac/Lin, but also for iOS, Android, and BB10
   

So at the end of the day, the world we live in looks a bit like this to me:

Back to the future: the good old tried and tested X client/server model anyone?

Now, while things look pretty neat the way they are already, how about going one step further? Namely, consider you decide to write your apps' UI based on a minimalist restriction of what HTML5 has to offer, e.g. you'll only use a limited set of widgets (say buttons, drop-down lists, and check-boxes), you'll use only an [editable] text area for all your text interactions, a canvas and an image renderer for graphics, and a simple file system API (well, this is prolly "too minimalistic" a set of UI functions, but i'm picking it up here just to get my message across); in this case, once your app is written based solely on (such) a subset of functions, what you'll have at the end of the day is a native app which will require a UI renderer with a very limited set of capabilities, such that not only you can use a standard HTML5 renderer on systems where it is available, but you can also build a minimalist UI renderer of your own (in native code) on systems that do not provide an HTML renderer: more specifically, where ever you'll find a POSIX(-like) system it's very likely you'll be able to get a port of WebKit (or even a full-fledged browser) for a pretty decent price (if not for free altogether), but if you are about to build an entirely new system of your own, then porting the Linux kernel (or writing a new fully POSIX-compliant kernel of your own) just in order to get WebKit running would be a titanic work that no ordinary small(ish) company can put up with all by itself.

And this is where the minimalist UI model comes into play: if you can have the GNU toolchain ported on your system (which should be pretty easy stuff, especially if you use an existing processor architecture - e.g. there's the OpenRISC out there for grabbing, and it comes with GNU toolchain support and all right out of the box), then all you'll have to do is to implement your small(ish) UI spec (e.g. in C++) and compile it with your gcc, and there you go, you'll have your apps truly cross-platform, ready to be deployed as-is both on any (minimalist) systems that implement your UI spec, and also on any systems that have an HTML5 browser:

The no-brainer solution: have your apps truly cross-platform-ready with a minimalist UI spec

Well, you tell me if i am wrong, but in my view (and given all of the above) this year may well become the most significant milestone in the evolution of standards-based programming after the standardization of ANSI C back in 1969.

PS
Apparently we'll still have to cope with writing BSD sockets wrappers for a while until/if they'll eventually be included in the C++ stdlib, but quite frankly that's a pretty trivial piece of code (given that we have standardized multi-threading baked inside C++) and not much more then a residual problem nowadays.

WebRTC starts flexing its muscles

During the past two years since i started working on P2P OS there has been some significant progress on the WebRTC project which two years ago looked more like a statement of intent than anything else; and since WebRTC is backed by big players like Google, Mozilla, and Opera (with Microsoft notably missing from this lineup after it flushed $8 billion down the drain last year on Skype and it's now pitifully crying foul and trying to screw things up again), it might eventually turn into a viable P2P solution that could make P2P OS rather redundant. However, while a side-by-side comparison between P2P OS and WebRTC does have some merit, i think the case for which of the two will come on top (in terms of quintessential project goals) is far from being settled at this point in time, mainly because WebRTC pays little to no attention to properly dealing with the very real (and critical) problems that the real-world internet topology of today and tomorrow pose to P2P connectivity: in a nutshell, WebRTC opted for a conservative SIP-like technology wherein it falls back to using a network of dedicated TURN relay servers whenever a direct P2P connection between two nodes cannot be made, with little consideration to the fact that such a relay server network requires some big-pockets "sponsors" that can throw in enough ca$h to keep it up and running (e.g. Viber pumps some $2.5 million a year to keep its rather small-ish network up and running), and i think it's very likely that users will be forced to have/get a Google/Mozilla/Opera/M$/whatever account in order to use the service.

Alternatively, P2P OS aims at creating a self-reliant P2P network which is meant by design to gracefully navigate both the rough waters of the current IPv4 exhaustion and IPv4-to-IPv6 transition, and the promised shiny days of a P2P-friendly IPv6-only world of the decades ahead. Also, the scope of P2P OS is not restricted to point-to-point communication between nodes; instead, its design goal is to provide a generic foundation for content-centric networking (a.k.a. named data) where point-to-point communication is only one of many use case scenarios.

To rise, while i can see WebRTC as a serious potential competitor to P2P OS, i think abandoning P2P OS because of WebRTC would be premature at this point in time.

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.

• note: there are two new port management protocols currently being baked in the IETF and UPnP Committee labs, with each of them promising a significant positive impact on the feasibility of the P2P topology presented in this post should they be widely deployed, namely UPnP's IPv6 firewall control service and the IPv4/IPv6 port control protocol, with the latter apparently being eagerly awaited by CGN OEMs and ISPs
  

In other news:
Qt5 is out, with my stalking here: https://bugreports.qt-project.org/browse/QTBUG-28461

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 (Free.fr, 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:

• http://www.evaluationengineering.com/articles/201209/service-providers-the-ipv6-bell-tolls-for-thee.php
• http://www.internetsociety.org/deploy360/blog/2012/04/comcast-rolling-out-home-gateway-support-for-ipv6-and-nothings-controversial-about-a-64/
• http://www.attinnovationspace.com/innovation/story/a7782696
• http://www.swissipv6council.ch/sites/default/files/images/ipv6-residential-swisscom.pdf
• http://www.telekom.com/media/company/93184
• http://www.ipv6.org.sa/sites/default/files/IPv6_Progress_Status_STC.pdf
• http://www.rcs-rds.ro/internet-digi-net/ipv6

...and some live stats by ISPs here: http://www.worldipv6launch.org/measurements/

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.

PS
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.

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.