lunes, 19 de mayo de 2014

Internet6 keeps its growth while IoT appears to be a "Killer App"

This post is about understanding how providing Internet6 to end customers has finally become a main trend in 2014 as more and more ISPs are joining the move. In parallel, experts say success of booming Internet applications such as IoT may highly depend on IPv6 roll out.

Let's update & analyze the stats on leading countries (our previous analysis: Feb-2013, 15 months ago).

The pic included above (source: Eric Vyncke stats) let us conclude at first: 
  • USA shows an exponential growth: up to 7,25%, from 2,23% in 2013 and 0,42% in 2012.
  • Germany the same: now 7,98%, from 1,16% in 2013 and 0,17% in 2012. 
The two above are extremely important countries due to their tech influence and demographic weight  in their respective regions.

We also see countries that have joined the race with a extremely good performance:
  • Belgium tops with 16,45% (it was 0,88% in 2013!). Also Switzerland with 10,68% (1,07% in 2013) and Luxemburg -not shown in the pic- with 7,95% (3,69% in 2013) show that many countries in Europe want to lead innovation in IPv6 services.
  • We also see other promising countries in EU: Norway, Czech Republic and Portugal.
  • In Latin America, Peru is the unbeatable leader with up to 4,83% (it was 0,25% in 2013 and plain 0 in 2012). 
  • China - not shown- shows some increase from 0,67% in 2013 up to 0,84%.
On the "more work/attention is needed" side we see:
  • India, that goes from 0,27% in 2013 to 0,09% today.
  • Brazil, which might have a significant influence, only goes from 0,04% to 0,05%
  • France, doesn't grow this year, actually keeps it almost stable from 5,05% to 4,93%.
  • Romania, the leading country in EU before, comes down to 5,68% (from 8,21% in 2013).
  • All other countries in those regions that may miss the opportunities given by this game-changer.

Obviously, the conclusion is that IPv6 to end users is growing exponentially in tech leading countries that also count with the highest number of Internet accesses, such as US and Germany and it is only a question of time that others will follow behind. We can also conclude that numbers really grow quickly then.

What's the risk of being late then? The actual problem is failing to deliver innovative scenarios & opportunities to entrepreneurs, developers, innovators, startups & all other companies in those countries.

App & Services developers should also pay attention to this trend, as long as millions of users might choose an IPv6-enabled alternative, if proven more efficient or functional.
Selling worldwide, App developers must not care if IPv6 is rolled out in their region. However, knowing where millions of v6-enabled users appear is truly relevant in order to know how and where launching a v6-capable or even v6-only product means and opportunity.

Here we go!

The next diagram shows IPv6 daily traffic in AMS-IX exchange point in Europe. It has grown up to almost 20Gb peaks.

The yearly evolution suggests average traffic got more than double as of May2013.

"Things" will use the new Internet to get connected

With all this growth going on, some experts start to point out IoT as a potential field of application of the Internet6, even with the consideration of potential killer-application.

Read more on IPv6 relevance for IoT at:

However, do not underestimate the applicability of Internet6 for any product that might be benefitted from distributed architectures and simplified networking.

Finally, App developers deploy the logic of their services in the Cloud, so the next post will attempt to discuss a comparison of IPv6-ready public and private Clouds commercial/experimental offering.

Enjoy and get your Apps & networks ready for the future!

More news and updates at Twitter: @carlosralli  

jueves, 7 de noviembre de 2013

i6station: Contributing to an OpenSource specific project

This post is about a software project I am contributing to during my free time together with other software developers. It aims to exploit IPv6 specific advantages in real life scenarios.
If you are a developer willing to contribute or just learn v6-coding for fun, do not hesitate to join the i6hub (placeholder of i6station and other projects).

The main idea of i6station is to lower the barriers for developers [ including some of us ;-) ] to quickly build Apps/Services oriented to common life scenarios such as: a home, a conference or event, a friend's meeting, a car, etc.

The bet today is building services solely based on smartphones+cloud resources.
While these 2 sources meant thousands of ideas to become true, there are potential new ones not fitting or performing well into that simple approach:

  1. Services exploiting local resources we cannot (or don't want to) connect, upload nor share in the Cloud (public Internet). This means normally Communications & resources we want to keep local for efficiency or security purposes.
  2. New local network settings we would like to deploy (a multicast channel, a dedicated Wifi, a v6 tunnel to enable incoming traffic to local services, IP-mobility, etc).
  3. Address places where there is no (good) Internet connectivity or we lack the connectivity type we wish. 

i6station aims to complete the fast growing world of Apps with open (and cheap) hardware that is physically installed in the same location Apps/services are provided. Of course one may argue that someone may use a smartphone for that, but certainly you just don't want to empty your phone battery, share it or risk its integrity.

The first and main reason I decided to join this initiative is the idea of building a v6-specific platform meaning that IPv6 advantages are given a strong priority compared to v4 backwards compatibility.

The second reason is the selected open hardware platform is the well-known Raspberry Pi that I really love to work with, previously at home for my DIY projects, and nowadays also at work as a result of those own personal hobbies.

The 3rd reason is the chose model is a platform model. In the beginning the idea was more to build up some services for those environments but after some brainstormings the new direction is to build a "platformized" product.
Then It's is not only about building standalone Apps but, at the same time, not attempting a super-mega-platform for others usage. Just develop for ourselves to be able to develop more ideas and faster in the future. If more people join, great but that is not the unique or central goal.

The final -and key- reason is the platform will be 100% opensource and Apps built on top may have any license they wish, just mention they are built ontop. Let's make things usable, no limits, that's it.

From a developer's point of view, the PI+i6station will expose lots of local resources with the successful and easy-to-learn REST APIs model, which will be served mainly over CoAP/UDP/IPv6, or sometimes over HTTP/TCP/IPv6. IPv4 might be also used, but features are never guaranteed in such a legacy environment.

Finally, some ideas we believe v6-specific model helps to:

  • We can deploy many local IP public or private networks with different prefixes for different devices or services/Apps. We give the freedom to the App for creating those subnets, let's enable developers to create network domains with no network commands knowledge at all.
    • As a reference we will check what is being worked out by IETF Homenet WG.
  • We can always choose to use public addressing or ULA addresses.
    • ULA is similar to v4 private but we avoid two problems:
      • 1) limited number of nodes in the network
      • 2) potential overlapping when merging networks.
  • We ensure P2P services (including those based in WebRTC) will always work and they will be offered in the most efficient way.
    • For home environments we will check latest proposed access configurations (draft-v6ops-vyncke-balanced-ipv6-security-01.txt, Jul 2013)
  • We integrate CoAP/6LowPAN m2m networks without introducing proxies or translators.
  • We introduce new possibilities with IPv6 staless auto configuration.
  • We introduce new possibilities with IPv6 renumbering.
  • We introduce new possibilities with IPv6 mobility.
  • We introduce new possibilities with IPv6 security Headers.
  • We introduce new possibilities with IPv6 multicast.
  • We are in the best position to explore and incorporate new possibilities that entities (SDOs such as IETF, research centers, universities or companies) will develop only for IPv6 once it gets massively deployed and thus used as main Internet transport.
  • If we focus on IPv6 for this new product, we remove the chains of IPv4 and legacy devices. For them, we can provide proxies or specific module-interfaces.

If you follow or join this project, just Enjoy as much as I'm doing!  :-)

martes, 21 de mayo de 2013

Peru & Telefonica lead the number of IPv6 users in LatinAmerica

This short post aims to report the explosive growth of Internet6 users that Peru is experiencing during the last months. The relevance is twofold: it is the first country in Latinamerica region with a serious IPv6 uptake and it is also the first spanish-speaking leading country. Telefonica del Peru is the ISP behind this numbers, according to the Telefonica press release linked below.

Folks, I have been observing the latest statistics in the region of Latin-America and it seems that Peru IPv6 customers are increasing at an exponential rate (Now it is about 2,10% out of the total accesses to Google originated in this country).

Using the methodology presented in a previous post, I conclude there are about 226,496 IPv6 users in this country, becoming the absolute leader of IPv6 deployment within this region.

If you are designing and developing IPv6-only/enabled Digital products or services, do consider to serve them in Spanish too, as long as Latinamerica is getting on board!

Today, 6/6/2013, Telefonica has published a press release stating a relevant deployment in this country that is obviously the cause of Peru leading numbers. These are excellent news in such a day, the first anniversary of the World IPv6 Launch Day.

- English: Telefonica leads IPv6 deployment in Latin America

- Spanish: Telefonica lidera el despliegue de IPv6 en Lationamerica

Congrats to Peru and my colleagues at Telefonica del Peru!

jueves, 18 de abril de 2013

Internet6: Enabling the Web of Things

This post describes how the IPv6 Internet brings a new approach for m2m or IoT services resulting on a number of benefits for all players in the value chain as well as opportunities in pretty different vertical businesses, such as: geek-like gadgets, smart homes, connected cars, smartcities, logistics, e-health, etc. 
To write this article a bunch of previous studies and hands-on with real sensors was needed. The collaboration and good ideas of my colleague and friend Cristina Peña (@crisisP) are an essential part of those results. If you want to read a similar resource in Spanish language, follow this link.

How is the machine-to-machine landscape today?

Most M2M systems are based on sensors or actuators that use some kind of low-level communication protocol to communicate to a gateway which, in turn, enables users' interaction, service creation or expose services/APIs to local or remote platforms or Apps.
Some communication low-level protocols work over existing or new wiring and others work over radio systems. Many times they tend to be proprietary protocols, far from the IP convergence that is happening in most domains.
On the contrary, IoT gateways are typically connected using the standard TCP/IP to the Internet, normally over 2,5G/3G/LTE, Wifi or wired access points.
This way, most Internet of Things implement the generic model drawn in the following diagram.

Actually, I am myself a fan of home smart devices for a long time at home. My current setting does follow the model presented above:

While my own setting works fine, X-10 usage of home power wiring results on unreliability at many other installations. At the same time, RF X-10 sensors are normally unidirectional and with limited coverage and reliability.

Several new technologies have been developed to improve the historic but still popular and cheap X-10 for smarthomes. In parallel, others have been developed for industrial applications or other sectors where reliability and other features are a must.
Popular wired solutions are Lonworks, KNX (very popular wired system for smarthomes in EU) and, similarly, well-known wireless solutions today are Zigbee or Z-wave.
Zigbee and Z-way are both proprietary technologies that implement bidirectional devices improving reliability and coverage by the means of  radio meshed networks (IEEE 802.15.4), where nodes may use others to route messages to a gateway.
Devices send and receive messages to/from the gateway, that might implement local services or be connected to the Internet and expose services or APIs to remote platforms or Apps.

The Web of Things

The following picture shows a different and emerging model, where sensors are truly nodes of the Internet and expose Web services themselves.
This model enables sensors to send observations directly to the customers using direct unicast links, a hierarchy of relays or even multicast flows. This enables new approaches saving resources, complexity and costs at the m2m backend, that still may manage the registration, configuration and actuation over the devices.
Moreover, in some specific scenarios devices could directly be managed by end-user Apps (e.g. from a mobile) without the intervention of an m2m backend.

In contrast, what we have seen so far are devices connected to gateways that offer services. Normally, APIs exposed to remote apps or platforms are provided over the successful REST WEB paradigm.
REST model exposes resources via URIs (WEB resources) and remote clients are able to perform CRUD (Create, Read, Update, Delete) operations over them. For instance, you can send a command to a sensor or get an observation from it by accessing the proper URI (e.g. http/server/home-sensors/temperature/living-room) at the server with the correct HTTP method and payload (normally XML or JSON descriptions).

The next two sections explain the technologies delivered by the IETF to make this a feasible paradigm and further sections explain available commercial implementations and how you can get to play with it, if interested.

6LowPAN: efficiently making sensors nodes in the Internet6 

Electronics integration advances and economy-scale have resulted in powerful and cheap radio-mesh sensors operated by regular 1,5V AAA batteries during one year or more.
Such devices are perfectly able to run an embedded reduced OS (Operating System) that includes a TCP/IP stack, libraries for Web services, and basic REST services exposed to the overall Internet.
However, IP is not efficient at that level because of the headers overhead and link-layer convergence mechanisms.

This exactly what the IETF has been lately working out, creating an specific IP protocol for WSN (Wireless Sensor Networks) or LowPANs (Low-power PANs).
Obviously, in order to have enough addresses for sensors and avoid the need of NATs, what the IETF has actually delivered is an IPv6 protocol for those networks, known as "6LowPAN".

6LowPAN is basically an IPv6 with extremely compressed headers and much more efficient protocols for routing, neighbor discovery, etc. Because of this, it still needs a gateway to get connected to the Internet6, but differently to other solutions such as zigbee or z-wave, the gateway only operates at the OSI layer 3, behaving more as a router between the 6LowPAN domain and the outer world.
Therefore sensors are real Internet6 nodes that can be even pinged from any node, if the security policies allow that to happen.

6LowPAN has become an emerging technology with a respectable wide implementation  by different companies and open software and hardware initiatives, as described in further sections of this article.

CoAP: making sensors service plane efficient for 6LowPAN comms

As said before, m2m platforms normally expose services exploiting the successful REST model that relays on HTTP/TCP.
The problem of using the same model for sensors to expose services is that TCP is a connection-oriented protocol introducing plenty of overhead due to session establishment (3-way handshake) flow control and retransmissions in case packets are lost (an often fact in LowPAN networks).

In order to optimize communications at this level, the IETF CORE WG has delivered CoAP, an application level protocol that we can consider a REST implementation (CRUD operations) over UDP.
CoAP has been designed to be fully compatible with the current Web infrastructure, including existing proxies, new CoAP-HTTP proxies, browsers, etc.

CoAP has been largely implemented so far. There exist libraries available for C, C++, Java and Python.
We can also find CoAP libraries in embedded open Operating Systems with 6LowPAN support for sensors (e.g. ContikiOS, TinyOS).

Detailed Architecture of the Internet6 Web of Things

As shown in the following diagram, sensors provide services via CoAP (over 6LowPAN) that might be translated later to HTTP/IPv6. However, we can also think on clients directly accessing CoAP URIs.

The following diagram describes all the protocols and stacks involved in this model.

Existing Internet6 Web of Things Products & Solutions

Sensinode: Building the 'Embedded Web'

Sensinode is Finland-based company that is, in my opinion, an example of pioneering the above-described 'Web of Things' paradigm. They are also major contributors in the IETF for the standardization of  6LoWPAN and CoAP and they were a founder of the IPSO Alliance.

Sensinode has developed a complete commercial end-to-end software solution at the devices and backend platform sides.
The following snapshot is directly taken from their WEB product description, where more information is available.

With such a product and technology expertise, Sensinode is offering solutions right today for connected homes, lighting control and smart grid networking.

Arch Rock 6LowPAN stack/devices

Arch Rock Corporation is a systems and software company that builds innovative products and technology for wireless sensor networks. The company was founded in 2005 and is based in San Francisco, California, and was acquired by Cisco in Sep 20th 2010.
As described in this white-paper, Arch Rock was bringing an IPv6 Network Stack for Wireless Sensor Networks as early as in 2007.
Arch rock has largely contributed to standardization as well. An example is their contribution in 2008 to this "Interoperability Test for 6LoWPAN" IETF draft, together with Sensinode corporation introduced above.

As a curious example, the winery cellar of Vinton Cerf (also known as one of the 'fathers of Internet') shown in LAs Vegas CES 2013 is based on Arch Rock 6LowPAN devices and stack.

BTW, Vinton Cerf has actually been one of the promoters of IPv6 adoption.
I had the extremely nice opportunity to make an IPv6 Video-on-Demand demo to him long time ago as part of an event related to his "Fathers of Internet" prize in the "Principe de Asturias Awards" (Spain, 2002). Let me remind a bit those wonder years, with a picture of that moment.

My colleague Antonio Lucientes (@AntLucientes) also in the picture. Of course, more colleagues (@CrisisP , @AmandaAzTer , @auro74, @alien1912 and others) were not in the picture, but at the backoffice making all the demo to work too!  :-)

An Android operated LED-bulb. Google first incursion in Internet6 m2m?

In 2011 Google's I/O developers conference the Montain View company announced an demoed "a competitively priced and supremely energy-efficient omnidirectional 60-watt equivalent light bulb with a small, embedded computer chip that can be turned on and off or dimmed with your Android-equipped smartphone, laptop, or tablet".
According to this article, such an Android LED bulb was to be based on the 6LowPAN standard.
However, in this techcrunch note in 2012 they doubt if that was really to happen as a commercial product. On the other hand, this recent post in March 2013 opens the possibility of further work.

Despite of Google's strategy or plans on this regard, the fact is to develop this kind of bulb is feasible and it has been schematized by NXP manufacturer (JenNet-IP solution).
The following diagram shows the whole architecture of the service. Yes, all in the bulb chipset!

The DIY (Do-It-Yourself) way

Wanna prototype m2m solutions with 6LowPAN & CoAP? Keep on reading ...

While normally software has become a commodity available to the broad community to create solutions, devices (hardware) have been a closed realm where only large specific companies or harware savvy could prototype, test and deliver solutions. This fact has recently changed with the appearance of open hardware kits, that include powerful microprocessors for the standards of this domain, such as Arduino, shields for Arduino including myriads of functionalities, sensor motes, etc.
There is even a circuit called Zigduino based on the generic Arduino, and fully compatible with its shields, that includes the IEEE802.15.4 chipset for radio mesehed network communications.

To complete the whole picture new tiny PC-like cheap boxes have appeared in the market enabling anyone to easily develop m2m gateways. A good example is the well-known Raspberry-PI type B suitable for this applications, using a free and open linux-based OS and sold at a price of $35.

As a consecuence, nowadays prototyping and building complete m2m solutions is easier and cheaper than any other time before.

The statement above is also valid for 6LowPAN and CoAP sensor technologies, so this is my contribution as a kind DYI manual on this:

1. A first item to select is the free operating system to use in the sensors. I have checked ContikiOS and TinyOS both with lots of supported hardware platforms.
ContikiOS is programmed in C while C# used in TinyOS. There are many resources in the web to compare both platforms. In my case, I selected ContikiOS.

2. Once you selected an embedded OS, you have to select a hardware platform.
In my case, I did a first analysis with the supported Contiki hardware page.
If you like to make your own hardware you have to choose those chipsets supported by the OS and then design and create your circuit board. There are also multiple examples of boards available in the net.
If you do not feel to play so much with hardware you need to find out a provider of "motes" which are basic prototypes with some sensors onboard and often come with a USB to make tests with your PC quite easy.

Regarding ContikiOS, I found several providers. Some of them are:
  • Zolertia, a Barcelona (Spain) based company, that sells Z1 motes at a very competitive price.
  • Advanticsys, a Madrid (Spain) based company, selling also XM1000 motes at a good price.
  • Zigduino. This is actually an Arduino clon with an IEEE802.15.4 radio meshed network chipset. If you're a fan of Arduino you may choose this one as long as Arduino shields are compatible. Another way is to add the proper radio shield to Arduino.
  • Redwire, a US based company, selling the porpular and cheap EconoTag motes.
  • Arago Systems, a Sophia Antipolis (France) based company, providing the wismote.
In my particular case, I selected Advanticsys XM1000 motes for my experiments. The company provides libraries for both TinyOS and ContikiOS.

3. Do not forget to buy one extra sensor or a USB gateway to connect a computer for the tests.
   In my case, I use another XM1000 motes connected to a MacBook Pro, but Advanticsys provides this specific USB dongle.

4. Install a VM in your computer to compile software that will be transferred to the actual sensors.
For the Contiki OS that I use, this is explained in detail in this page.

5. Develop your software using 6LowPAN and CoAP libraries in the OS. Compile the software and transfer it to one or more sensors to perform your trials. Enjoy!
If you go for ContikiOS as well, there are some first examples provided together with the standard distro that you installed in the virtual machine.


The following picture summarizes a recent study with a comparison of various ways to encapsulate REST operations, mainly to compare CoAP/UDP with previous approaches.

Future Work and further analysis 

There are mobile vendors that have started to consider 6LowPAN and CoAP technologies as a way to incorporate smart gadgets (measuring user heartbeats, number of steps, speed when running, etc)  and even wearable computers (textiles with embedded gadgets).

The key for this approach is the implementation of 6LowPAN over Bluetooth Low Energy so devices will talk to the mobile using that (instead of IEEE802.15.4 that is not expected to be supported by mobiles in the short term).
At the same time, the mobile device that is connected to the Internet via 3G or Wifi is an ideal placeholder for the 6LowPAN gateway and even v4-v6 translator/proxy.

In such a model, gadgets offer CoAP services to the user and to external platforms. Think for instance on a heartbeat sensor that normally provides the info to our sport-training platform and that automatically sends its observations to medical urgencies whenever abnormal periodicity or intensity of heartbeats are detected.

jueves, 14 de febrero de 2013

Where are IPv6-only apps potential customers?

This post aims to provide some light on where & how many potential customers of v6-only apps or products are in a per-country basis. Calculations are entirely based on the OECD Countries Internet Usage and Population Statistics & Eric Vyncke's site enabling easy comparisons based on Google per-country IPv6 statistics. Kudos to Eric for his really useful work!

Let's start first with my two pics summarizing the amount & location of v6-only potential customers:
(please note this is a draft approximation based on the methodology described below, so absolute numbers might not be accurate. It includes all kind of users, residential, academic, corporate users, mobile, wifi, etc. Should you have comments/corrections, I am glad to receive them).

To estimate the number of IPv6 users the following assumptions described below have been made:
  • Eventually, all Internet users did access Google once or more, given a sufficient period of time.
  • v4 and v6 users behave identically in what regards to accessing Google or not. 
As of the two previous conditions, we still cannot say "google v6 accesses = v6 users" of course, but we should be able to say "v6 users = (Internet users x % v6 google accesses)" as a valid approximation (at least this should be close to be true whenever the % of accesses is high enough so we know users behave statistically the same and noisy data is irrelevant).

Additionally, to avoid noisy data in the previous graphs, the following rules have been applied:
  •  Only countries with the highest number of v6 accesses or highest accesses growth at this time, as described in the sections below, have been considered.
  •  Countries with v6 % accesses below 0,1% have been discarded (i.e. highly populated countries with rates far below 0,1%, but still meaning lots of users anyway, are not drawn as few testers might be artificially increasing google hits over v6).
Conclusion: In my opinion, what they call 'Internet users' in the statistics might not mean regular or active users and, therefore, the effective number of them is lower. As a result v6-users as calculated here would be lower too. Perhaps a correction factor based on this assumption should be applied. However, I still think numbers as a reference and comparison to other countries are relevant.

If you are interested on per-region and per-country details, just keep reading.


In the previous post, I strongly suggested IPv6-only as one option to be considered by developers and entrepreneurs. A summary of my arguments follows:
  1. Avoid v4-Internet constraints for P2P & interactivity.
  2. Skip the transition mesh.
  3. Focus now onwards on differentiation, as many others are busy with 1 & 2.
  4. IPv6 users (your target users/customers) are rapidly growing reaching a critical mass.
In case you are a believer on the above, I think you might be interested to know how many potential customers there are and where they are located. I hope this post gives light on that or at least good sources to make numbers yourself ... I would be happy to know then! ;-)  

In the following sections, I highlight those countries within different world regions with a higher penetration of IPv6 or highest growth, according to Eric's page diagrams accessed on Feb 4th 2013. 

Please, note that by clicking the URL linked down the diagrams, you'll be redirected to Eric's site displaying current updated figures.

1) North America

The largest populated country in the region, US (313M)is leading this region with a good and stable rising trend. Therefore, US is definitely one of the main countries to address with your IPv6 apps, devices or products.

2) Europe

Europe is diverse in cultures and languages, so knowing in advance where your users or customers are or will be shortly is key.
Best in class, in terms of IPv6 end customers, are Romania (current world leader in %), France and Luxemburg.
France is one of the most populated (65M) and well connected countries in Europe, so it seems a proper place for IPv6 only entrepreneurs.

The following diagram shows another angle, EU countries with the highest growth at this point. We can see that Germany (DE) has started to rise over 1% early 2013 and it is actually the most populated country in Europe (81M).

Significant growths are also seen in Belgium (BE), Switzerland (CH), Holland (NL) and Portugal (PT).

Finally, other countries with a significant percentage of accesses (>0,1%) that you may consider in Europe are shown in the following diagram.

3) Asia

In the case of Asia, the 3 most populated countries are already suitable for IPv6 only apps.
Japan (127M) is leading, showing its historic and renewed commitment. Numbers could be even higher as we know some filtering was set up in 2011 aiming to reduce W6D'11 brokenness. I suspect numbers grow also as filters at some Japanese ISPs are removed when they know brokenness is actually solved.
China (1,343M) shows a more strange behavior that may need further study and India (1,205M) finally seems to have waken up since 2012 Q4 reaching now almost 0,3%.

The following diagram shows rising trends in Australia (22M), New Zeland, Hong Kong and Singapore. 

4) Latam

Latinamerica has not yet joined relevant growths for the most relevant/populated countries.  Perhaps, because it seems that IPv4 depletion is expected to happen later compared to other regions.

To look for potential users one should stay tuned to this diagram with Brasil (193M), Chile (17M), Argentina (42M), Uruguay (3M) and Mexico (112M):

There has not been a big move so far. However, there are some countries in the region that are starting to show some interesting variations, maybe due to some tests or early deployments, namely: Peru, Cuba, Ecuador and Honduras.