GEN6 PP D5 6 2 v0.6 · !297239! GEN6! D5.6.2!Monitoring!of!IPv6!in!Academic!Networks!! 22/05/2015!–!v0.6! Page8of 26! ! 1. INTRODUCTION’ 1.1 Context’and’Motivation’ The!goal!

© GEN6 Consortium

Title: Document Version:

Deliverable D 5.6.2 Monitoring of IPv6 in Academic Networks-‐2

0.6

Project Number: Project Acronym: Project Title:

297239 GEN6 Governments ENabled with IPv6

Contractual Delivery Date: Actual Delivery Date: Deliverable Type* -‐ Security**:

31/03/2015 10/05/2015 R – PP * Type: P -‐ Prototype, R -‐ Report, D -‐ Demonstrator, O -‐ Other ** Security Class: PU-‐ Public, PP – Restricted to other programme participants (including the Commission), RE – Restricted to a group

defined by the consortium (including the Commission), CO – Confidential, only for members of the consortium (including the Commission)

Responsible and Editor/Author: Organization: Contributing WP:

Fernando Mira da Silva IST WP5

Authors (organisations):

José Costa (IST), David Duarte (IST), Jorge Matias (IST), Fernando M. Silva (IST), João Marques (IST) Tiago Machado (IST), Luis G. Silva (IST)

Abstract:

This deliverable is an update report on the work performed in the scope of WP5 in order to monitor effective IPv6 usage access in academic networks.

Keywords:

IPv6, Governments, Academic IPv6, Monitoring Data, DNS support.

297239 GEN6 D5.6.2 Monitoring of IPv6 in Academic Networks

22/05/2015 – v0.6 Page 2 of 26

Revision History The following table describes the main changes done in this document since its creation.

Revision Date Description Author (Organization)

V0.1 18/11/2014 Document creation José Costa (IST)

V0.2 15/04/2015 First revision Fernando M. Silva(IST)

V 0.3 17/04/2015 Sensor and monitoring description updated David Duarte (IST), Jorge Matias(IST(

V0.4 20/04/2015 Web site design description João Marques (IST), Tiago Machado (IST)

V0.5 6/05/2015 Consolidation Fernando M. Silva (IST)

V0.6 8/05/2015 Conclusions added Fernando M. Silva (IST)


22/05/2015 – v0.6 Page 3 of 26

Disclaimer The GEN6 project (number 261584) is co-‐funded by the European Commission under the ICT Policy Support Programme (PSP) as part of the Competitiveness and Innovation framework Programme (CIP). This document contains material that is the copyright of certain GEN6 partners and the EC, and that may be shared, reproduced or copied “as is”, following the Creative Commons “Attribution-‐NonCommercial-‐NoDerivs 3.0 Unported (CC BY-‐NC-‐NC 3.0) licence. Consequently, you’re free to share (copy, distribute, transmit) this work, but you need to respect the attribution (respecting the project and authors names, organizations, logos and including the project web site URL “http://www.gen6.eu”), for non-‐commercial use only, and without any alteration, transformation or build upon this work.

The information herein does not necessarily express the opinion of the EC. The EC is not responsible for any use that might be made of data appearing herein. The GEN6 partners do not warrant that the information contained herein is capable of use, or that use of the information is free from risk, and so do not accept liability for loss or damage suffered by any person using this information.


22/05/2015 – v0.6 Page 4 of 26

Executive Summary The GEN6 academic pilot aims to collect the experience and results of IPv6 deployment scenarios coming from participating Universities, namely KIT and IST, and monitoring the IPv6 deployment in Academia across Europe. This report addresses the technical work performed in the scope of monitoring the IPv6 deployment in Academia.

The main goal of this activity is the development and installation of an adequate software sensor in highly demanded pages that enable the effective use of IPv6 at the user level in academic institutions. This activity requires the cooperation of main Universities, by the installation of a link to the developed sensor on their main sites, in order to attempt to achieve a relevant number of accesses from within academic networks.

This report is an updated version of previous Deliverable D.5.6.1, including the work performed in the period M33-‐M39. It revises the methodology adopted for sensor development, the corrections performed the last project phase and the work developed in order to promote the this monitoring task and dissemination of the probe.

Deliverable D.5.6.1 covered the sensor development and the preliminary results obtained from this project phase. In this first phase of the work, it was required to adapt previously existing sensor probes to the specific requirements of this monitoring activity and to develop adequate filtering and statistic processing of the collected raw data in order to obtain relevant results and to test the developed system and processing methodology. Therefore, in the first phase of this activity, the probe was installed and tested at IST websites only. Preliminary results, described in the previous deliverable, showed the consistency of the probe. However, the limited scope of deployment showed also that the results had reduced statistical significance and that a wider dissemination of the probe was required in order to achieve more meaningful results.

The first attempts to improve the deployment of the probe in Academic sites showed that the lack of a public site with on-‐line monitoring results was a major drawback to further dissemination of the probe. In fact, given the lack of feedback data, it was difficult to promote the installation of a probe, since network administrators and webmasters had few incentives to its installation. This limitation was identified before, and in fact the development of a site for on-‐line publishing of the monitoring results was already foreseen as a required component for a successful deployment of the probe.

In the last project phase, a large effort was devoted to the development of a high quality site for on-‐line publishing and dissemination of monitoring data. As an outcome of this effort, it was developed the site http://gen6.tecnico.ulisboa.pt/, where detailed results of the monitoring activity were published and detailed in several formats.


22/05/2015 – v0.6 Page 5 of 26

After the site was published on-‐line, a first formal request for installation of the probe was forwarded to all Universities making part of @CLUSTER, an association of 12 leading European Universities of Science and Technology.

This report, further to update technical details of data collection and statistical reporting, describes the deployment of the site http://gen6.tecnico.ulisboa.pt/, as well as the dissemination actions taken so far.


22/05/2015 – v0.6 Page 6 of 26

Table of Contents 1. Introduction .................................................................................................................................................. 8

1.1 Context and Motivation ......................................................................................................................... 8

1.2 Contents Overview ................................................................................................................................ 9

2. Methodology .............................................................................................................................................. 10

2.1 Overview ............................................................................................................................................. 10

2.2 Probe description ................................................................................................................................. 11

2.3 Data processing .................................................................................................................................... 15

2.4 Database server API ............................................................................................................................. 15

2.5 Security and reliability ......................................................................................................................... 16

2.6 Major challenges .................................................................................................................................. 17

3. Monitoring Website .................................................................................................................................... 19

3.1 Motivation and scope .......................................................................................................................... 19

3.2 Design overview ................................................................................................................................... 19

3.3 Design Methodology ............................................................................................................................ 19

3.4 Web technology and resources ............................................................................................................ 20

3.5 Website structure overview ................................................................................................................. 20

3.6 Scoreboard .......................................................................................................................................... 21

3.7 Data per institution .............................................................................................................................. 22

4. Discussion ................................................................................................................................................... 24

5. References .................................................................................................................................................. 26


22/05/2015 – v0.6 Page 7 of 26

Figure Index Figure 1 -‐ Overall architecture of the GEN6 probe model ....................................................................... 12 Figure 2 – Test structure overview ......................................................................................................... 13 Figure 3 -‐ Overall structure of the scoreboard ........................................................................................ 21 Figure 4 -‐ Detailed data per institution .................................................................................................. 22


22/05/2015 – v0.6 Page 8 of 26

1. INTRODUCTION

1.1 Context and Motivation

The goal of the GEN6 academic pilot was to collect the experience and results of IPv6 deployment scenarios coming from participating Universities, namely KIT and IST, and monitoring the IPv6 deployment in Academia across Europe.

One of the main goals of the pilot is to assess the maturity level of IPv6 implementation and deployment on academic institutions and Universities across Europe, including both technological and non-‐technological based schools, including the monitoring of the effective IPv6 use at the user level.

The GÉANT network is the pan-‐European research and education network that interconnects Europe’s National Research and Education Networks (NRENs). The GÉANT backbone fully supports IPv6, as well as the majority of all NREN networks. However, IPv6 penetration at the Institution level and user is quite variable, and depends strongly on the local effort and commitment of CIO’s and local network administrators.

Global IPv6 Academic traffic data can be partially collected from the GÉANT backbone and also from some NRENs. The support of IPv6 in the backbone and services of main European Universities can also be tested using IPv6 queries to the central services of those institutions, which easily reports if the central services support IPv6 connectivity, as well as if IPv6 is available in services as www, mail or DNS. In fact, this data was collected and reported elsewhere in the scope of GEN6 WP5, as a joint effort of academic pilot partners and CZ.NIC. However, the assessment of the effective IPv6 deployment in the academia at the user level is not an easy task, since it is hard to directly monitor the IPv6 deployment in academic access networks. In fact, while some Universities already support IPv6 in their backbone and central services, the assessment of effective IPv6 deployment in distribution and access networks is a more difficult task.

The goal of the academic monitoring task is the installation of adequate software sensors in highly demanded pages of the academic community. Each access to such page triggers a small probe that tests connectivity to a dedicated IPv6 monitoring site, which enables to check if the source network and device supports IPv6. Aggregated data collected by such probes provides an improved estimate of the effective use of IPv6 at the user level in the source academic institution. In order to reach this goal and to obtain statistical relevant results, this task requires the cooperation of main Universities, or other public sites with popular content on the academic community, by installing the software probe in such sites. In order to improve and promote the dissemination of the probe, it was developed a dedicated website where this


22/05/2015 – v0.6 Page 9 of 26

activity is described and where the aggregated data is published and updated daily, providing a useful feedback to all participating universities.

This document revises the methodology adopted for the development of both the sensor and the monitoring website. Regarding the sensor, it was adapted a previously existing sensor probe to the specific requirements of this monitoring activity. Moreover, it was developed adequate filtering and statistical processing of the collected raw data in order to obtain meaningful results. Concerning the monitoring website, reachable at http://gen6.tecnico.ulisboa.pt/, this document describes the methodology adopted to develop the website and its overall structure.

Finally, this document describes several steps taken in order to improve the reliability and security of the probe and website.

This deliverable is devoted only to technical details related to the monitoring methodology and website development. The analysis of the actual monitoring data is reported in deliverable D4.5 (Report on maturity and penetration of IPv6 services in academic networks).

1.2 Contents Overview

The structure of this document is as follows. Section 2 describes the overall methodology used for the monitoring activity. It describes the details of the software sensor, how it can be installed in a web page, its output, and how this output can be used to gather statistics on IPv6 penetration in Academia across Europe. This chapter also discusses some major challenges that had to be addressed in order to achieve more reliable and accurate results. In Section 3, we describe the steps followed in the development of the site for publishing on-‐line monitoring results, and we describe the overall structure of the site. Finally, in Section 4, we discuss achieved results and further dissemination activities that are required in order to improve the data collected so far.


22/05/2015 – v0.6 Page 10 of 26

2. METHODOLOGY

2.1 Overview

The first step in order to monitor the implementation level at the access network in target universities, it was created a specific web service and DNS service. When accessing a site with the probe installed, the user is redirected to these services. Access logs to these services provide detailed information about IP source, protocols supported and further access information. All this raw data is recorded and subject to adequate filtering and statistical analysis in order to provide meaningful information about IPv6 penetration and support in the access network.

In order to achieve this goal, Web and DNS services were configured in order to reply to requests in the following connectivity scenarios:

1. HTTP address is available only in IPv4 and DNS service is available in dual stack;

2. HTTP address is available only in IPv6 and DNS service is available in dual stack;

3. HTTP address is available in dual stack and DNS service is available in dual stack;

4. HTTP address is available only in IPv4 and DNS is only available in IPv6;

5. HTTP address is available in several IPv6 addresses and DNS is available in dual stack.

These configuration scenarios intend to test the ability of the DNS resolvers to access other DNS servers, both when these are only available in IPv6 and when they are available in dual stack. The last test attempts to monitor the behavior of the service when a single domain name has a long list of IPv6 addresses associated (20, in the specific test performed). In this case, the reply is too long and the reply should be provided over TCP instead of UDP (RFC 1035 [1]). This test enables to test TCP support and to identify firewall configurations that may block this reply.

In order to promote the access to the Web/DNS service where this monitoring is preformed, it was developed a small software probe, developed in Javascript, which is designed to be installed in web sites where accesses from academic users is common. In practice, to reach this goal, the installation of the probe was envisaged in main European University websites, since these are institutions open to research and that, by their own nature, do have a high number of accesses from the academic community. However, one must emphasize that the location of the probe itself is irrelevant for the tests performed in the scope of this activity. In fact, IPv6 support is tested between the user platform and the IST test server, irrespective of the probe location. Therefore, any public site with a potential high number of accesses from academic networks is a good potential candidate for installation of the probe.


22/05/2015 – v0.6 Page 11 of 26

As stated before, the probe is just a small piece of Javascript adapted from a previous version by the IPv6 observatory [2]. The goal of the probe is to make the user Web Browser to make several accesses to the test web and DNS services, installed at IST. The details of this probe are described in deeper detail in section 2.2.

In order to obtain specific data concerning IPv6 support in academic networks, it is necessary to identify if the source of each access to the test services is made from a University or Academic institution, and filter out other accesses. Since the source IP address is known, it should be easy to identify the source network. In order to identify the source network, the extensive use of the IANA whois service [3] and the RIPE database [4] is made. In practice, this mapping has proved to be a harder task than initially anticipated, and in fact some degree of error still exists regarding the identification of academic networks. This subject is addressed in deeper detail in section 2.5.

If the source IP address is identified as an academic network, for each access to the test services the following data is recorded:

• User source IP address;

• University name;

• Web server;

• Operating system and web browser;

• Access date.

In order to associate each test set to a single access, and to avoid counting repeated accesses from the same source, it was required to develop a method to enable the identification of a single access. We will describe this method in deeper detail in section 2.2.

2.2 Probe description

As stated before, the developed probe is an updated version of the one originally developed by the IPv6 observatory [2], modified in order to perform the tests foreseen in the scope of this workpackage. The goal is to insert the probe in the HTML of several web sites with popular academic content, in order to be executed by the user web browser, and to identify accesses with source in academic networks. As stated before, the most practical way to achieve this goal is to attempt to install the probe in the main website of large Universities.

The reference to the probe is as simple as possible. The only requirement is to install the following HTML code in the target web site:


22/05/2015 – v0.6 Page 12 of 26

<script type="text/javascript">

document.write(decodeURI("%3Cscript src='" + document.location.protocol +

"//static.gen6.tecnico.ulisboa.pt/gen6.js' type='text/javascript'%3E%3C/script%3E"));

</script>

The sensor probe was developed in such a way that minimizes load and latency overhead when the user accesses the main website, keeping in practice the extra time unnoticeable at user level. Moreover, it is suggested to cooperating sites to install the probe code at the very end of the target page, just before the final tag </body>. While the overhead of the probe is minimal, this option avoids that the performed tests affect somehow the load time of the main web content.

When the browser executes the probe code, one HTTP GET request is sent to each of five different virtual test web sites installed at IST. Each one of these accesses simply downloads the smaller transparent image one may create (1px by 1px). This small image is designed in order to imply the effective access to the test sites, but in fact does not introduce any perturbation to the graphic content of the web site, being unnoticeable by the end user.

The overall architecture of this process is represented in Figure 1.

Figure 1 -‐ Overall architecture of the GEN6 probe model


22/05/2015 – v0.6 Page 13 of 26

Figure 2 – Test structure overview

As a result of this access, relevant access data is recorded. In practice, log data enables to perform the following tests, each one performed by an attempt to access a specific gen6 virtual host:

1. Access to the IST test site in IPv4 only (virtual host v4.gen6.tecnico.ulisboa.pt);

2. Access to the IST test site in IPv6 only (virtual host v6only.gen6.tecnico.ulisboa.pt);

3. Access to the IST test site available in dual stack (virtual host dualstack.gen6.tecnico.ulisboa.pt);

4. Access to the IST test site in IPv4 only, but for which the DNS only supplies an IPv6 reply (virtual host v4.gen66.gen6.tecnico.ulisboa.pt);

5. Access to the IST test site in IPv6 only, and for which the DNS supplies a large reply with 20 IP addresses (virtual host bigreply.gen6.tecnico.ulisboa.pt).

A graphic diagram depicting an overview of these tests is shown in Figure 2. Note that while the tests are triggered by the user access to the host website, all subsequent relevant tests are run directly between the end user and the IPv6 test servers located at IST, without any intervention of the hosting website. This methodology shows that the hosting website does not need to be strictly located at an Academic site or to support IPv6 in order produce relevant statistical data. If a user located in an IPv6 academic network of University A accesses the probe at any hosting site B, academic or non academic, in either IPv4 or IPv6, all relevant tests are run between academic network of University A and the gen6 test servers. The gen6 probe will only collect


22/05/2015 – v0.6 Page 14 of 26

data related with user IPv6 support at University A. No data relate with the hosting site will be collected as a result of this test.

Overall, these tests provide two types of information:

• Connectivity tests in IPv4 and IPv6 between the user device and the IST test site;

• Connectivity tests to the local DNS resolver, performed by the user device.

In the scope of the above tests, the following information about the user access is collected:

• If the user is able to access to the test site in IPv4 (base test);

• If the user is able to access the test site in IPv6 and, if positive, which type of addressing is used (e.g. IPv6 native, Teredo tunneling, 6to4 tunneling, etc..);

• To identify the preferred access protocol chosen by the end user device (IPv4 or IPv6).

Note that while in dual stack implementations the preferred access protocol should always be IPv6, some drivers switch to IPv4 not only when they detect unresponsive IPv6 requests, but also when they detect larger latencies or some other perturbation. Therefore, dual stack support with preferred IPv4 access may in practice arise more often than expected.

In the scope of the connectivity tests performed to the DNS server, the following information is collected:

1. If the resolver has IPv6 connectivity to obtain addresses from domain names;

2. If the resolver uses IPv6 over IPv4 tunnels in which MTU limits may prevent to resolve domain names in IPv6.

3. If there the local firewall configuration disables the resolver to receive TCP connections, which are required to resolve DNS replies of large dimension.

In order to identify accesses were made by the same single user, it is generated a unique identifier which is added to each Full Qualified Domain Name (FQDN) retrieved from the access to the Web/DNS test servers. Moreover, in order to avoid that the same user repeats the tests whenever it accesses the probe in each site where it is deployed, it is generated a local Javascript cookie in the first access, which indicates whether the tests were already performed or not. This cookie times-‐out after 24 hours.

All requests to the Web and DNS test servers are stored in local log files. These log files are periodically processed in order to monitor the supported IP protocol from each source IP and to generate the desired statistics and access reports.


22/05/2015 – v0.6 Page 15 of 26

2.3 Data processing

All monitoring data is collected in specific log files, where raw data is stored for further processing. A specific software module was developed in order to process this raw data, filter out results from non academic networks, process it and integrate it in a consolidated and structured database of Universities and other Academic institutions. This software module is run once daily in order to update the consolidated database, from where relevant summary statistics are obtained.

As stated before, raw data includes the source IPv4 and IPv6 addresses. The owner of each IPv4 or IPv6 address is identified by an access to the RIPE database in order to identify the source identity. In order to avoid the cap that the RIPE imposes in the number of daily accesses from a given IP, it was built and integrated in the local gen6 database a cache with all previously accessed IP blocks and associated entity. With this approach, a much faster processing is achieved, while ate the same time it is minimized the risk of reaching the RIPE daily limit.

In order to identify if the source address belongs to a University, a fuzzy pattern matching is performed in order to identify names usually associated with academic networks. Whenever a new institution is identified, a second RIPE query is performed in order to try to identify all IP blocks that were registered in the same name. This approach provides a faster and more efficient population of the local cache database.

One of the main difficulties of this process is that owner of each IP block is often recorded in an unstructured way in the RIPE database. In other words, slight variations of the entity name may occur as a result of the different blocks having being registered in different moments in time. Moreover, University merging, splits, change of names or local registration procedures further difficult this process, often requiring more manual processing that it would be desirable. More on this topic is addressed in section 2.5.

As stated before, the database records collected daily data. In order to provide more relevant and consolidated data, and at the same time to avoid weekly fluctuations resulting from weekends and holidays, a monthly aggregated view is recorded and published in the website.

2.4 Database server API

In order to provide data to the monitoring academic website, described in more detail in section 3, it was developed a simple API (Application Programming Interface) to access the data available in the database. The development of this API, further to provide a flexible way to access the available data by the web server, may also be used in the future to offer a convenient interface to access the monitoring data by authorized entities or other applications. However, just for now, its only purpose is to serve the academic website, and therefore only a


22/05/2015 – v0.6 Page 16 of 26

small set of entry points was defined in the interface. However, this API may be easily extended in the future, if further functions or different data views are required.

The API was developed using a conventional REST (Representational State Transfer) architecture. For the actual data exchange, a simple JSON (JavaScript Object Notation) format was defined, given its flexibility and simpler integration with site Javascript.

Currently, the API provides the following endpoints:

• /adoption – returns the global evolution of the rate of IPv6 accesses to the probe since July 2014 up to the current month.

• /adoption/begin/:begin/end/:end – returns the global evolution of the rate of IPv6 accesses to the probe since the date specified by :begin to the date specified by :end. Each field date must be supplied in the form mm.yyyy (for example, 12.2014 for December 2014).

• /scoreboard – return the information required to fill the scoreboard displayed on the website (check section 3 for further information).

• /university/:id – returns the time evolution of the different type of accesses from each University.

As stated before, this API is currently only available for internal use by the local web server. However, it may opened, whenever required, to other sites and applications

2.5 Security and reliability

In order to increase the security and trustworthy of the gen6 test server, all http requests to the test server are automatically redirected to a secure https connection, with a certificate signed by a trusted CA (Certificate Authority). This covers, further to the public main data website (gen6.tecnico.ulisboa.pt), the javascript probe and all gen6 virtual test sites. Therefore, signed certificates where also installed for the following virtual hosts:

• v4.gen6.tecnico.ulisboa.pt;

• v6only.gen6.tecnico.ulisboa.pt;

• bigreply.gen6.tecnico.ulisboa.pt;

• v4.gen66.gen6.tecnico.ulisboa.pt;

• dualstack.gen6.tecnico.ulisboa.pt.

Further to these, a wild card certificate was also generated for the whole domain *.gen6.tecnico.ulisboa.pt.


22/05/2015 – v0.6 Page 17 of 26

2.6 Major challenges

The goal of this task is to monitor IPv6 support in academic networks. In fact, while the probe will be mainly deployed in academic websites, recorded data will include accesses both from academic and non-‐academic networks. Therefore, as referenced in sections 2.2 and 2.3, it is necessary to identify the source IP and to check if the source access was performed from a University network. This requires performing a reverse look-‐up of the source IP address, and to use public services as the IANA whois database and the RIPE database to identify the IP owner and, from the data collected from these services, to identify if it belongs to an academic network.

However, this task proved to be much more difficult than previously anticipated. In practice, the following challenges were identified:

1. There is not a well established database which states whether a given IP block belongs or not to a University;

2. It is not easy to obtain a full list of all Universities and Higher Education Institutions in Europe;

3. When accessing the Whois and RIPE database, several difficulties also arise:

o The RIPE database is not uniform:

§ Each University may have several IP blocks;

§ Each IP block often has a different text description;

§ The text description is often found in different languages;

o In several cases, IP blocks belong to Faculties or other institutions within a single University. In these cases, it is required to associates these institutions to the correct University in order to have a coherent set of results. This has proven a difficult and, in several cases, an almost impossible job;

o The official owner of a given IP block is very often outdated. With the high number of institutional name changes, merge, fusion and split of Universities observed in the last few years, the official IP databases are plenty of outdated and noisy data, to say the least;

o Same University IP blocks do not have any information that enables their association to a given University;

o The RIPE database has a daily limit of 1,000 accesses. In order to minimize the risk of reaching this limit, a local cache database was developed, as described in section 2.3.

Given the factors above, the automatic merge of different records is difficult and


22/05/2015 – v0.6 Page 18 of 26

its association to a single University usually requires human supervision and manual processing.

o

4. In its current form, the probe is able to identify if the user has already made an access to the test site in the last 24 hours and to avoid duplicated daily accesses. Moreover, this strategy reduces the slightly higher load latency (even if often unnoticeable) to the first access in each 24-‐hour frame. The 24 hours limit is a somewhat arbitrary value. However, it was defined as a compromise value, which avoids the duplicated accounting of daily accesses and, at the same time, to deal with possible daily changes in user locations. For example, if a larger data time frame would be adopted, if the user accesses the host website from home (at a Sunday, for example), subsequent accesses within such larger time frame would be ignored, even if in subsequent days he/she would be located in at the academy. On the other hand, one must be aware that repeated accesses from the same user, in different days, are accounted as different accesses, even if his/her location is the same everyday. As stated before, only an increased dissemination and deployment of the probe will be able to contribute to filter out such statistical fluctuations.


22/05/2015 – v0.6 Page 19 of 26

3. MONITORING WEBSITE

3.1 Motivation and scope

As stated before, the first attempts to deploy the probe in some different Academic sites showed that the lack of a public site where the results could be visualized was a major drawback to further dissemination of the probe. In fact, given the lack of feedback data, it was difficult to promote the installation of a probe, since network administrators and webmasters had few incentives to its deployment.

While the development of the website was, since the start of the Academic Pilot, identified as target outcome of the project, it was first envisaged as site were the final statistics of the project would be published after the deployment of the probe in a significant number of sites and a set of relevant statistics recorded. However, as stated before, it was later understood that making the GEN6 academic statistics public was in turn a main requirement for a wider acceptance and dissemination of the probe.

Therefore, in order to improve the acceptance of the project, it was decided to invest on the development of a quality site, with professional design quality and a smooth integration with the database server.

3.2 Design overview

The website was developed following a user-‐centric design approach. The chosen methodology was based in the so-‐called atomic interface design, as well as fast development cycles based on the stakeholder’s feedback.

The development process took into account the best practices in web development, namely adopting a responsive web design. As an outcome of this approach, the final website provides a good viewing and interaction across a wide range of devices, from desktop computers to mobile phones.

3.3 Design Methodology

The web design methodology followed the following process workflow:

1. Stakeholder survey interview;

2. Definition of the project briefing;

3. Definition of the technical specifications;

4. Benchmarking;


22/05/2015 – v0.6 Page 20 of 26

5. Definition of the information architecture;

6. Development of intermediate (non functional) medium fidelity and high fidelity prototypes;

7. Front end development and functional modules;

8. Test and deployment;

9. Final tests;

10. Support and on-‐line update corrections.

3.4 Web technology and resources

The website was developed using the last revision of HTML5 [5] and CSS3 [6] language in the development of the front-‐end, enhanced with SASS pre-‐processor [7].

The website used the JavaScript library HighCharts [8] for the presentation and visualization of dynamic data and data graphs.

The site adopted fonts from the project Google fonts [9] for the text and the project Entypo for the iconography [10].

3.5 Website structure overview

The project website is available at https://gen6.tecnico.ulisboa.pt/technical/.

The main goals on the development of the site were to provide a short, but informative, description of the scope of the GEN6 project and of the Academic Pilot, to enable on-‐line access to IPv6 statistics and to promote the participation of further Universities in the process. Since concerns regarding data privacy were identified as a major reserve to the deployment of the probe in some Universities, a specific section detailing strict data privacy guidelines was included in the site and referenced in several places.

The overall site include the following sections and subsections:

• Project o About o Statistics o Participate o Contacts

• More Info o About this site o Privacy policy o Technical information


22/05/2015 – v0.6 Page 21 of 26

While the snippet with the sensor code and installation instructions could have been made publicly available without any prior registration, we opted to follow a slightly more restrictive approach. The code snippet and installations instructions are sent by email upon filling a short form with the contact name and e-‐mail and target website, available in the Participate subsection of the website. Note that there is not any validation of this form and the email with the required data is sent at once to any requestor. However, this approach provides a more accurate monitoring of valid requests to install the sensor probe.

The GEN6 academic monitoring website includes itself, further to the GEN6 probe, a Google analytics probe. This last probe provides an accurate and detailed report of accesses to the website.

As it would be expected, the most relevant pages of the site are those related with display of statistical results. We describe these specific pages in further detail in the following subsections.

3.6 Scoreboard

The Scoreboard is a simple ordered list of Academic institutions, along with the level of the IPv6 adoption and its ranking in the Times Higher Education World University Rankings 2014-‐2015. The overall structure of the displayed data is shown in Figure 3.

Figure 3 -‐ Overall structure of the scoreboard


22/05/2015 – v0.6 Page 22 of 26

Data can be sorted in direct or reverse order using as sorting key any of the columns. Further to this, it is possible a easier and more direct access to the data of any specific University by using an adequate search string in the provided search box.

3.7 Data per institution

Detailed data per institution is available from the scoreboard selecting any line of the list. The overall structure of this page is show in Figure 4.

The main chart provides the monthly evolution of the number of connections to the test site, as well as the number of IPv6 connections. The smaller charts display the evolution of dualstack connections with IPv6 preferred, IPv6 only, dualstack with IPv4 preferred, and IPv4 only.

Figure 4 -‐ Detailed data per institution


22/05/2015 – v0.6 Page 23 of 26

Note that given the different scales of the vertical axis, the relative evolution of the smaller graphics may be slightly misleading at the first sight. However, using the mouse over in each chart point pops up a small window with the numeric data, which enables a better interpretation of the displayed data. Moreover, the relative weight of each access type is clearly available from the pie chart in the right.


22/05/2015 – v0.6 Page 24 of 26

4. DISCUSSION

As it was identified since the beginning of the project, and as it was also pointed out in deliverable D.5.6.1, the achievement of meaningful statistical results would require a wider dissemination and deployment of the probe. However, the deployment of the probe itself would only be possible after its development and an intensive test phase. In fact, any problems that the deployment of the probe in its early development stages could inject in cooperating hosting websites had the potential to compromise the overall task.

When the probe reached a confortable maturity status, it was requested its inclusion in some cooperating websites. This first dissemination stage enabled to identify a couple of bottlenecks and some scalability problems were addressed.

However, the first contacts made to deploy the probe in other Academic sites showed that the lack of a public site with on-‐line monitoring results was a major drawback to further dissemination of the project. In fact, given the lack of feedback data, it was difficult to promote the installation of the probe, since network administrators and webmasters had few incentives to its installation. This limitation was identified before, and in fact the development of a site for on-‐line publishing of the monitoring results was already foreseen as a required component for a successful deployment of the probe.

However, it was not possible to start the development of the site before the development of the probe and the identification of the relevant statistics that would be collected. Unhappily, the design of the site and its integration with the statistical database took more time that previously anticipated. On the other hand, the public deployment and dissemination of the site was only possible after all the preliminary probe tests and tuning proved that it would supply fairly reliable results. As it was discussed in section 2.5, a further difficulty that had to be overcome prior to the publication of the site was the database cleaning process, in order to properly merge different RIPE entries and to identify academic networks. This was mostly a intensive time consuming manual cleaning process, which proved to be much more complex and costly than previously anticipated. While this is and will be a required periodic task while the site will be up, it required a much larger effort during the initial deployment phase.

The restrictions above proved to be a “chicken and egg” problem. In fact, further dissemination of the probe was difficult before the deployment of the site. On the other hand, it was considered that the dissemination of the site before having a minimum amount of reliable bootstrap data should be avoided. In spite of the cooperation of some public Portuguese websites and from the University of Murcia during this bootstrap process, added to the short time span of the Academic Pilot, delayed the dissemination of the site and the effective collection of statistical data.


22/05/2015 – v0.6 Page 25 of 26

Therefore, only in the very late stage of the project a formal request was sent to all @CLUSTER universities with a formal request to cooperate in this activity, along with the website address. While we expect that a positive reply from some major universities will be able to drastically improve the statistics collected up to now, current on-‐line results are still restricted in scope and further dissemination work is required in order to collect more accurate data.

Provisions were made to keep the GEN6 academic website on-‐line for a long time span. Therefore, we expect that the number of cooperating Universities will increase in the near future and that this will contribute to improve the accuracy of the data collected so far.


22/05/2015 – v0.6 Page 26 of 26

5. REFERENCES

[1] RFC 1035 -‐ DOMAIN NAMES -‐ IMPLEMENTATION AND SPECIFICATION,

https://www.ietf.org/rfc/rfc1035.txt. Accessed 15 Sep. 2014.

[2] IPv6 Observatoy Indicators, http://www.ipv6observatory.eu/indicators/, accessed 15 Sep. 2014.

[3] IANA whois service, https://www.iana.org/whois, accessed 15 Sep. 2014.

[4] Ripe database, http://www.ripe.net/data-‐tools/db, accessed 15 Sep. 2014.

[5] HTML5: A vocabulary and associated APIs for HTML and XHTML, W3C Recommendation 28 October 2014,

http://www.w3.org/TR/html5/, accessed 20 April 2015.

[6] CSS specifications, W3C, http://www.w3.org/Style/CSS/current-‐work, accessed 20 April 2015.

[7] SASS, http://sass-‐lang.com, accessed 20 April 2015.

[8] Highcharts, http://www.highcharts.com/, accessed 20 April 2015.

[9] Google fonts project, https://www.google.com/fonts, accessed 20 April 2015.

[10] http://www.entypo.com/, accessed 20 April 2015.

Documents

GEN6 PP D5 6 2 v0.6 · !297239! GEN6! D5.6.2!Monitoring!of!IPv6!in!Academic!Networks!! 22/05/2015!–!v0.6! Page8of 26! ! 1. INTRODUCTION’ 1.1 Context’and’Motivation’ The!goal!