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