This post provides developers with an introduction to developing IPv6-aware and accessible Apps/Products with FIWARE & FIWARE Lab. Thanks to our IPv6 expert, #arroba#CarlosRalli, for his collaboration!
Last June 6th was the 2nd anniversary of the World IPv6 Launch Day, so I decided to add my 2 cents with this post by spreading the word to developers, now that several ISPs are massively rolling out IPv6 access to their fixed and mobile subscribers. Learn more on current IPv6 worldwide uptake stats in this article.
If you are a developer and you are willing to get real experience or you are just curious on v6-enabled Cloud Apps, just keep on reading!
Additionally, IPv6 experts or enthusiasts may find here a pragmatic educational and experimental resource to create developers’ awareness so we all speed up the delivery of v6 enabled Internet services & products.
By the way: if you know nothing about FI-WARE & FI-Lab you may prefer to scroll down right now to “What are FI-WARE & FI-Lab?” at the end of this article.
Target Testing Scenario
Tests in this article involve FI-Lab’s v6-enabled Orion ContextBroker GEs, which enables your App to be a provider (push) and/or consumer (query or subscribe) of FI-Lab ecosystem’s Context information (i.e. Smartcities in the diagram above).
Regarding your testing infrastructure, you’ll most likely have no IPv6 native cellular (3G/4G) access, so we propose two alternatives:
1. Use a Laptop for initial tests.
In this first scenario, if your home-ISP is not providing you with a native IPv6 connection, you may still go on with an IPv6-over-IPv4 tunnel, which is a service offered by many TunnelBroker providers and it works quite fine for most Home broadband accesses.
Setting up your own IPv6 tunnel is an easy process by using, for instance, Hurricane Electric TunnelBroker service.
Once you have a working tunnel in your laptop, test your v6-connectivity to Google and to our machines as depicted in the following diagram.
2. Use a smartphone connected over Wifi.
If your home ISP is providing IPv6, you may safely test your smartphone’s v6 readiness with “IPv6 ToolKit” App (by James Hamilton, for iphone) or “IPv6 and more” (by Rahul Sen, for Android). If that is not the case, you need first to set up a tunnel to a computer -similarly to (1)- and configure it as an ipv6-enabled Wifi router.
Find in these posts how to set up a RaspberryPi for that purpose:
http://www.linuxhome.co.uk/?p=274
http://tlfabian.blogspot.com.es/2014/04/how-to-setup-raspberry-pi-as-ipv6.html
Unfortunately, if your App needs a backend server able to talk IPv6 you cannot use any FI-Lab developers’ VMs today as they are not v6-enabled. Just stay tuned as we are working on this! See section “The whole picture: An IPv6 view of the FI-Lab today” below for more information on this.
First Step: Get an account in FI-Lab & an Oauth2 access token
FI-Lab public GEs are secured with an Oauth2 infrastructure deployed as a central user accounts portal via KeyRock IdM (Identity Manager) GE and a set of PEP-proxy GEs in between your connections and any GE you are actually accessing to.
The necessary steps to be able to access FI-Lab’s secured GEs are:
1. Sign up in FI-Lab and get an account. http://account.lab.fi-ware.org
2. Generate an Oauth2 access token using your credentials in (1).
The easiest to test is to use the script provided at:
https://github.com/fgalan/oauth2-example-orion-client/blob/master/token_script.sh
Note that the Token to be used is the 1st: “Access Token” (the longest).
3. Access the ContextBroker REST API with an authorization header set to the access token received in (2).Here we just make a simple test to one v6-enabled ContextBroker.
Here we go! Now that we have been able to reach a secured IPv6 ContextBroker, let’s analyze which resources you can access or provide to FI-Lab.
Second step: Connect your IPv6 App to FI-LAB’s IPv6 Orion ContextBrokers
As said before, Orion is a v6-ready ContextBroker GE implementation thought as a publish/subscribe component, which forwards and store entities, their attributes and metadata.
For the initial IPv6-enabled offering, that we may call Fi-Lab6 now onwards, we have deployed two v6 ContextBrokers:
- orion2.lab6.fi-ware.org [2001:720:1514:80::44], with the following connected tenants/services:
– Sevilla Smartcity: with water consumption counters and Fountain sensors.
– ipv6tests: for initial IPv6 testing, where v6 testers can push info.
- orion3.lab6.fi-ware.org [2001:720:1514:80::45], with the following connected tenants/services:
– Santander Smartcity: Traffic, Sound, light level and many otgher sensors.
You may consume (read) resources’ context from any of the tenants/services above and you are able to push (write) context information to the “ipv6tests” one.
There is a complete manual on how to consume or provide context data from/to orion ContextBroker, including the conventions needed to access specific sensor information of the smartcities mentioned above.
https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide#FI-LAB_context_management_platform
The following capture shows a test to get all sound sensors connected from Santander smartcity:
The whole picture: An IPv6 view of the FI-Lab today & roadmap
This section is targeted to those developers or IPv6 experts willing to know how we provide FI-Lab IPv6-ready GEs plus our current roadmap to grow up to a full v6-enabled Cloud of components.
The following picture attempts to draw a high level view of FI-Lab and its IPv6 enabled resources.
Let’s analyze the diagram above in a bottom-to-top way:
- Data Center Connectivity: The Datacenter where the Cloud is deployed needs to be first connect to the IPv6 Internet and needs to request an adequate IPv6 prefix (IPv6 addressing)In the case of FI-Lab the core infrastructure is deployed in RedIRIS (Spanish NREN) which holds native carrier-grade v6 peerings (10Gbps) with GEANT ( pan-European network) plus some Tier-1/2 commercial backbones.
- Datacenter Network infrastructure: Besides, all Datacenter network segments and routing elements that we will use to deploy our Cloud need to be configured with IPv6 addressing (after an addressing plan is established) and IPv6 routing among all segments and external networks.Additional facilities may include specific IPv6 firewalls, IPv6 Load-balancers and IPv6 Multicast routers.In the case of FI-Lab this was an easy step as long as RedIRIS deploys all their new networks with IPv6 in mind.
- Physical Machines: Normally these are industrial PCs where a virtualization layer will deploy Virtual Machines holding the software components. These machines need to be configured with IPv6 addresses and routes. In the case of FI-Lab only Phy machines not belonging to Openstack Virtualization platform have been configured as this Cloud platform is not yet configured for v6.
- Virtualization Layer: FI-Lab components run mainly in an Openstack environment so this is the main virtualization layer/platform to provide VMs for FI-WARE components and Developers’ VMs (used by them to deploy their App backend in the Cloud).
The point is that official releases of Openstack do not support IPv6 (nor v6-enabled VMs) and this has been a main stopper so far for testing IPv6 with FI-WARE components. In order to address this issue we are currently running two parallel strategies:
1 – Enable other virtualization layer: manually deploying VMs with KVM to start to test some components. This is the case for the v6-ready components explained in this article.
The plus side is that we are then able to offer v6-accesible components to developers right know and start debugging but unfortunately, management of manual VMs prevents us to offer developers v6-enabled VMs for their backends. Alternatively, developers need to simulate the backend in a local laptop or use any existing IPv6-ready Cloud service.
See examples here.
2 – Test Nephos6 paper to enable IPv6 in Openstack Havana Release. We have indeed started with an experimental Cloud, not with FI-Lab so this will take some time but it is aimed to be the final solution.
- virtual Machines: as discussed before all Openstack VMs are not v6-capable by now. However, we have been able to deploy some KVM VMs that host the v6-ready components explained in this post.
- Security Layer: FI-Lab security layer is composed by a User accounts portal connected to the IdM (identity Manager) GE that runs in an Openstack VM and thus is not v6-capable. However, the software itself supports well IPv6 so we can configure the PEP-Proxy covering each protected GE with IPv6 whenever they are in a v6-enabled VM.
- FI-WARE (Public) Components: After all public FI-WARE components are installed in VMs and secured with a PEP-Proxy. For our current experiment we have deployed two Orion ContextBrokers protected with their respective PEP-Proxies, all communicating over IPv6. The frontend for the developer is actually the PEP-Proxy which is dual-stack (v4+v6) but will always forward authorized queries to the ContextBroker over IPv6 (even when the query to the PEP-Proxy is done over IPv4).
Next Steps
Prior to have an Openstack supporting v6-VMs we will:
- Deploy more v6-ready components over KVM VMs: So more components can be tested.
- Deploy a v6 to v4 proxy to offer a v6 connection to the User Accounts Portal of the IdM, even when the indoor pipe is kept in v4 we offer this way a v6 frontend to developers/users browsers.
- Deploy a PEP-proxy in a VM to offer a v6 front-end to a v4-only component in the Openstack Cloud. This will be done only if strongly needed.
Finally, once our Cloud team gets a v6-ready Openstack Cloud, we will be able to offer all the infrastructure and v6-ready components over v6 and v4.
Conclusions
From this work and the previous studies I’ve collected these personal following insights:
- Customer products’ developers are poorly aware of IPv6 and what it may mean for them. Even those who do, they assume they have no way to get it today and therefore leave the learning task for the future.
- Platform components’ developers are aware they will need to support IPv6 in some point but they do not see ready infrastructures and potential users. However, in FI-WARE teams such as Orion ContextBroker and KeyRock IdM have quickly realized it is at least a nice-to-have feature.
- Datacenter infrastructure/cloud guys see IPv6 as a closer milestone compared to developers and have normally tested it. However several tools they use today are not ready or not providing official support (Openstack Cloud, monitoring tools, etc.). For this reason, we do not see today many v6-ready commercial Clouds and existing ones are reluctant to move quickly.
- Seems there is an opportunity for innovative experimental Cloud platforms -such as FI-Lab- to start the IPv6 offering to the developers (both platform and final products). This will result in awakening their curiosity, the so-needed learning process and real life software testing & debugging.
- There exists the risk developers will keep backwards compatibility as a priority and also just copy&paste v4 proceedings and best practices for simplicity. Even in this case, developers getting to IPv6 first will enjoy some competitive advantage.
However, the maximum benefit will come if the ecosystem innovates on deploying products in a more efficient way and with extra features for the v6-only users’ traffic.
hosting service and the GEs are provided. The great thing is that several smartcities are connecting to the FI-LAB and this way they are offering open-data and real-time sensor events to be consumed by developer’s solutions. Cool, isn’t it?
All interfaces of the Generic Enablers are open REST APIs and are based in open standards easy to be understood and exploited by millions of web developers. Many of the components are provided with an open-source license model.
A datacenter may decide to install a FI-WARE compliant Cloud by selecting some specific components so its flexibility has been a key design goal.
FI-WARE is developed by a European consortium led by Telefónica I+D under the Future Internet Public-Private-Partnership (FI-PPP) of the European Commission.
Annex II: Why IPv6 In FI-WARE & FI-LAB?
The IPv6 protocol is being rolled out and therefore the Future Internet products will need to cope with it. FI-WARE components should be able to expose their REST APIs over IPv6 sooner or later.
Most entrepreneurs are focusing in the business cases they believe in and they just use the technology and tools that are delivered and explained to them. By providing this technology we contribute to developers’ awareness (very low today), those that will create solutions that will exploit the new protocol.
The IPv6 networks are said to have some potential benefits that will only emerge if the Internet services and products do not just copy and paste what it is done with IPv4 ones today, but they explore them and create useful innovations. By providing within FI-LAB an experimental v6-enabled platform we allow innovators to investigate this field.
Credits
This is truly a team work where special kudos have to be paid to the following colleagues collaborating with this initiative:
- Orion ContextBroker team at Telefonica I+D: for delivering a v6 ready production version allowing me to help with some minor contribs to the code.
- IoT Agent developers & Cloud guys at TI+D, providing lots of support & help to deploy the v6 testing platform.
- IdM team at UPM: for delivering a v6 ready product, tackling a potential bug and providing support for configuration.
- To all others contributing with ideas, suggestions, comments, etc.
