<?xml version="1.0" encoding="UTF-8"?><xml><records><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Yves Vanaubel</style></author><author><style face="normal" font="default" size="100%">Pascal Mérindol</style></author><author><style face="normal" font="default" size="100%">Jean-Jacques Pansiot</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">A Brief History of MPLS Usage in IPv6</style></title><secondary-title><style face="normal" font="default" size="100%">Passive and Active Measurement Conference (PAM)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">6PE tunnels</style></keyword><keyword><style  face="normal" font="default" size="100%">IPv6</style></keyword><keyword><style  face="normal" font="default" size="100%">LSE Stack</style></keyword><keyword><style  face="normal" font="default" size="100%">MPLS</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2016</style></year><pub-dates><date><style  face="normal" font="default" size="100%">03/2016</style></date></pub-dates></dates><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Recent researches have stated the fast deployment of IPv6. It&amp;nbsp;has been demonstrated that IPv6 grows much faster, being so more and more&amp;nbsp;adopted by both Internet service providers but also by servers and end-hosts.&amp;nbsp;In parallel, researches have been conducted to discover and assess the usage of&amp;nbsp;MPLS tunnels. Indeed, recent developments in the ICMP protocol make certain&lt;br /&gt;categories of MPLS tunnels transparent to traceroute probing. However, these&amp;nbsp;studies focus only on IPv4, where MPLS is strongly deployed.&lt;/p&gt;&lt;p&gt;In this paper, we provide a first look at how MPLS is used under IPv6&amp;nbsp;networks using traceroute data collected by CAIDA.&amp;nbsp;We have observed, at the first glance, that the MPLS deployment and usage seem to greatly differ between IPv4 and IPv6,&amp;nbsp;in particular in the way MPLS label stacks are used. While label stacks are not that frequent&amp;nbsp;in IPv4 (and mostly correspond to a VPN usage), they are prevalent in IPv6. &amp;nbsp;However, after a deeper look at the label stack typical content in IPv6, we understand that 2-label stack tunnels are mainly used for dual stack 6PE tunnels and ECMP load sharing purpose. &amp;nbsp;The technical deployment of such tunnels is really similar to VPN in practice but the objective is not the same (they are standard tunnels made with the IPv4 LDP for carrying IPv6 traffic).&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Yves Vanaubel</style></author><author><style face="normal" font="default" size="100%">Pascal Mérindol</style></author><author><style face="normal" font="default" size="100%">Jean-Jacques Pansiot</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">MPLS Under the Microscope: Revealing Actual Transit Path Diversity</style></title><secondary-title><style face="normal" font="default" size="100%">Internet Measurement Conference (IMC)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">ECMP</style></keyword><keyword><style  face="normal" font="default" size="100%">LDP</style></keyword><keyword><style  face="normal" font="default" size="100%">MPLS</style></keyword><keyword><style  face="normal" font="default" size="100%">multipath</style></keyword><keyword><style  face="normal" font="default" size="100%">network discovery</style></keyword><keyword><style  face="normal" font="default" size="100%">RSVP-TE</style></keyword><keyword><style  face="normal" font="default" size="100%">traceroute</style></keyword><keyword><style  face="normal" font="default" size="100%">traffic engineering</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2015</style></year><pub-dates><date><style  face="normal" font="default" size="100%">10/2015</style></date></pub-dates></dates><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Traffic Engineering (TE) is one of the keys for improving packet forwarding in&amp;nbsp;the Internet. It allows IP network operators to finely tune their forwarding&amp;nbsp;paths according to various customer needs. One of the most popular tool&amp;nbsp;available today for optimizing the use of networking resources is MPLS. On the&amp;nbsp;one hand, operators may use MPLS and label distribution mechanisms such as RSVP-TE&amp;nbsp;in conjunction with BGP to define multiple transit paths (for a given edge pair)&lt;br /&gt;verifying different constraints on their network. On the other hand, when&amp;nbsp;operators simply enable LDP for distributing MPLS labels in order to improve the&amp;nbsp;scalability of their network, another kind of path diversity may appear thanks&amp;nbsp;to the ECMP feature of IGP routing.&lt;/p&gt;&lt;p&gt;In this paper, using an MPLS labels analysis, we demonstrate that it is possible&amp;nbsp;to better understand the transit path diversity deployed within a given ISP.&amp;nbsp;More specifically, we introduce the Label Pattern Recognition (LPR) algorithm, a&amp;nbsp;method for analyzing traceroute data including MPLS information. LPR reveals&amp;nbsp;the actual usage of MPLS according to the inferred label distribution protocol and&amp;nbsp;is able to make the distinction between ECMP and TE multi-path forwarding.&amp;nbsp;Based on an extensive and longitudinal traceroute dataset obtained from CAIDA,&lt;br /&gt;we apply LPR and find that each ISP behavior is really specific in regard to its&amp;nbsp;MPLS usage. In particular, we are able to observe independently for each ISP&amp;nbsp;the MPLS path diversity and usage, and its evolution over time.&amp;nbsp;Globally speaking, the main outcomes of our study are that (&lt;em&gt;i&lt;/em&gt;) the usage of&amp;nbsp;MPLS has been increasing over the the last five years with basic encapsulation&amp;nbsp;being predominant, (&lt;em&gt;ii&lt;/em&gt;) path diversity is mainly provided thanks to ECMP and&amp;nbsp;LDP, and, (&lt;em&gt;iii&lt;/em&gt;), TE using MPLS is as common as MPLS without path diversity.&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Korian Edeline</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">Towards a Middlebox Policy Taxonomy: Path Impairments</style></title><secondary-title><style face="normal" font="default" size="100%">International Workshop on Network Science for Communication Networks (NetSciCom)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">classification</style></keyword><keyword><style  face="normal" font="default" size="100%">IPv6</style></keyword><keyword><style  face="normal" font="default" size="100%">middleboxes</style></keyword><keyword><style  face="normal" font="default" size="100%">path impairment</style></keyword><keyword><style  face="normal" font="default" size="100%">tracebox</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2015</style></year><pub-dates><date><style  face="normal" font="default" size="100%">04/2015</style></date></pub-dates></dates><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Recent years have seen the rise of middleboxes, such as firewalls, NATs, proxies,&amp;nbsp;or Deep Packet Inspectors. Those middleboxes play an important role in today's&amp;nbsp;Internet, including enterprise networks and cellular networks. However, despite&amp;nbsp;their huge success in modern network architecture, they have a negative impact&amp;nbsp;on the Internet evolution as they can slow down the TCP protocol evolution and its&amp;nbsp;extensions. Making available a summary of the potential middlebox network&amp;nbsp;interferences is of the highest importance as it could allow researchers to&amp;nbsp;confront their new transport protocol to potential issues caused by middleboxes.&amp;nbsp;And, consequently, allowing again innovation in the Internet.&lt;/p&gt;&lt;p&gt;This is exactly what we tackle in this paper. We propose a path impairment&amp;nbsp;oriented middlebox taxonomy that aims at categorizing the initial purpose of a&amp;nbsp;middlebox policy as well as its potential unexpected complications. Based on a&amp;nbsp;measurement campaign on IPv4 and IPv6 networks, we confront our taxonomy to the&amp;nbsp;real world. Our dataset is freely available.&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Valentin Thirion</style></author><author><style face="normal" font="default" size="100%">Korian Edeline</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">Tracking Middleboxes in the Mobile World with TraceboxAndroid</style></title><secondary-title><style face="normal" font="default" size="100%">7th International Workshop on Traffic Monitoring and Analysis (TMA)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">Android</style></keyword><keyword><style  face="normal" font="default" size="100%">tracebox</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2015</style></year><pub-dates><date><style  face="normal" font="default" size="100%">04/2015</style></date></pub-dates></dates><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Middleboxes are largely deployed over cellular networks. It is known that they&amp;nbsp;might disrupt network performance, expose users to security issues, and harm&amp;nbsp;protocols deployability. Further, hardly any network measurements tools for&amp;nbsp;smartphones are able to infer middlebox behaviors, specially if one cannot&amp;nbsp;control both ends of a path. In this paper, we present TraceboxAndroid a&lt;br /&gt;proof-of-concept measurement application for Android mobile devices&amp;nbsp;implementing the tracebox algorithm. It aims at diagnosing middlebox-impaired&amp;nbsp;paths by detecting and locating rewriting middleboxes. We analyze a dataset&amp;nbsp;sample to highlight the range of opportunities offered by TraceboxAndroid. We&amp;nbsp;show that TraceboxAndroid can be useful for mobile users as well as for the&lt;br /&gt;research community.&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Luca Cittadini</style></author><author><style face="normal" font="default" size="100%">Stefano Vissichio</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">On the Quality of BGP Route Collectors for iBGP Policy Inference</style></title><secondary-title><style face="normal" font="default" size="100%">IFIP Networking</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">bias</style></keyword><keyword><style  face="normal" font="default" size="100%">iBGP policies</style></keyword><keyword><style  face="normal" font="default" size="100%">measurement</style></keyword><keyword><style  face="normal" font="default" size="100%">network topology</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2014</style></year><pub-dates><date><style  face="normal" font="default" size="100%">June 2014</style></date></pub-dates></dates><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;A significant portion of what is known about Internet routing stems out from&amp;nbsp;public BGP datasets. For this reason, numerous research efforts were devoted to&amp;nbsp;(&lt;em&gt;i&lt;/em&gt;) assessing the (in)completeness of the datasets, (&lt;em&gt;ii&lt;/em&gt;) identifying biases&amp;nbsp;in the dataset, and (&lt;em&gt;iii&lt;/em&gt;) augmenting data quality by optimally placing new&amp;nbsp;collectors. However, those studies focused on techniques to extract information&amp;nbsp;about the AS-level Internet topology.&lt;/p&gt;&lt;p&gt;In this paper, we show that considering different metrics influences the&amp;nbsp;conclusions about biases and collector placement. Namely, we compare AS-level&amp;nbsp;topology discovery with \iac inference. We find that the same datasets exhibit&amp;nbsp;significantly diverse biases for these two metrics. For example, the sensitivity&amp;nbsp;to the number and position of collectors is noticeably different. Moreover, for&amp;nbsp;both metrics, the marginal utility of adding a new collector is strongly&amp;nbsp;localized with respect to the proximity of the collector. Our results suggest&amp;nbsp;that the ``optimal'' position for new collectors can only be defined with&amp;nbsp;respect to a specific metric, hence posing a fundamental trade-off for&amp;nbsp;maximizing the utility of extensions to the BGP data collection infrastructure.&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Yves Vanaubel</style></author><author><style face="normal" font="default" size="100%">Jean-Jacques Pansiot</style></author><author><style face="normal" font="default" size="100%">Pascal Mérindol</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">Network Fingerprinting: TTL-Based Router Signature</style></title><secondary-title><style face="normal" font="default" size="100%">ACM/USENIX Internet Measurement Conference (IMC)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">fingerprinting</style></keyword><keyword><style  face="normal" font="default" size="100%">initial TTL</style></keyword><keyword><style  face="normal" font="default" size="100%">MPLS router signature</style></keyword><keyword><style  face="normal" font="default" size="100%">network discovery</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2013</style></year><pub-dates><date><style  face="normal" font="default" size="100%">10/2013</style></date></pub-dates></dates><pub-location><style face="normal" font="default" size="100%">Barcelona, Spain</style></pub-location><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Fingerprinting networking equipment has many potential applications and benefits&amp;nbsp;in network management and security. More generally, it is useful for the&amp;nbsp;understanding of network structures and their behaviors. In this paper, we&amp;nbsp;describe a simple fingerprinting mechanism based on the initial TTL values used&amp;nbsp;by routers to reply to various probing messages. We show that main classes&lt;br /&gt;obtained using this simple mechanism are meaningful to distinguish routers&amp;nbsp;platforms. Besides, it comes at a very low additional cost compared to standard&amp;nbsp;active topology discovery measurements. As a proof of concept, we apply our&amp;nbsp;method to gain more insight on the behavior of MPLS routers and to, thus, more&amp;nbsp;accurately quantify their visible/invisible deployment.&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Yves Vanaubel</style></author><author><style face="normal" font="default" size="100%">Jean-Jacques Pansiot</style></author><author><style face="normal" font="default" size="100%">Pascal Mérindol</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">Network Fingerprinting: TTL-Based Router Signatures</style></title><secondary-title><style face="normal" font="default" size="100%">ACM Internet Measurement Conference (IMC)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">fingerprinting</style></keyword><keyword><style  face="normal" font="default" size="100%">initial TTL</style></keyword><keyword><style  face="normal" font="default" size="100%">MPLS</style></keyword><keyword><style  face="normal" font="default" size="100%">network discovery</style></keyword><keyword><style  face="normal" font="default" size="100%">router signatures</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2013</style></year><pub-dates><date><style  face="normal" font="default" size="100%">10/2013</style></date></pub-dates></dates><pub-location><style face="normal" font="default" size="100%">Barcelona, Spain</style></pub-location><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Fingerprinting networking equipment has many potential applications and benefits&amp;nbsp;in network management and security. More generally, it is useful for the&amp;nbsp;understanding of network structures and their behaviors. In this paper, we&amp;nbsp;describe a simple fingerprinting mechanism based on the initial TTL values used&amp;nbsp;by routers to reply to various probing messages. We show that main classes&amp;nbsp;obtained using this simple mechanism are meaningful to distinguish routers&lt;br /&gt;platforms. Besides, it comes at a very low additional cost compared to standard&amp;nbsp;active topology discovery measurements. As a proof of concept, we apply our&amp;nbsp;method to gain more insight on the behavior of MPLS routers and to, thus, more&amp;nbsp;accurately quantify their visible/invisible deployment.&lt;/p&gt;</style></abstract></record><record><source-app name="Biblio" version="7.x">Drupal-Biblio</source-app><ref-type>47</ref-type><contributors><authors><author><style face="normal" font="default" size="100%">Gregory Detal</style></author><author><style face="normal" font="default" size="100%">Benjamin Hesmans</style></author><author><style face="normal" font="default" size="100%">Olivier Bonaventure</style></author><author><style face="normal" font="default" size="100%">Yves Vanaubel</style></author><author><style face="normal" font="default" size="100%">Benoit Donnet</style></author></authors></contributors><titles><title><style face="normal" font="default" size="100%">Revealing Middlebox Interference with Tracebox</style></title><secondary-title><style face="normal" font="default" size="100%">ACM/USENIX Internet Measurement Conference (IMC)</style></secondary-title></titles><keywords><keyword><style  face="normal" font="default" size="100%">middlebox</style></keyword><keyword><style  face="normal" font="default" size="100%">network discovery</style></keyword><keyword><style  face="normal" font="default" size="100%">tracebox</style></keyword></keywords><dates><year><style  face="normal" font="default" size="100%">2013</style></year><pub-dates><date><style  face="normal" font="default" size="100%">10/2013</style></date></pub-dates></dates><language><style face="normal" font="default" size="100%">eng</style></language><abstract><style face="normal" font="default" size="100%">&lt;p&gt;Middleboxes such as firewalls, NAT, proxies, or Deep Pack-et Inspection play an&amp;nbsp;increasingly important role in various types of IP networks, including&amp;nbsp;enterprise and cellular networks. Recent studies have shed the light on their&amp;nbsp;impact on real traffic and the complexity of managing them. Network operators&amp;nbsp;and researchers have few tools to understand the impact of those boxes on any&lt;br /&gt;path. In this paper, we propose tracebox, an extension to the widely used&amp;nbsp;traceroute tool, that is capable of detecting various types of middlebox&amp;nbsp;interference over almost any path. &amp;nbsp;tracebox sends IP packets containing TCP&amp;nbsp;segments with different TTL values and analyses the packet encapsulated in the&amp;nbsp;returned ICMP messages. Further, as recent routers quote, in the ICMP message,&amp;nbsp;the entire IP packet that they received, tracebox is able to detect any&amp;nbsp;modification performed by upstream middleboxes. In addition, tracebox can often&amp;nbsp;pinpoint the network hop where the middlebox interference occurs. We evaluate&amp;nbsp;tracebox with measurements performed on PlanetLab nodes. Our analysis reveals&amp;nbsp;various types of middleboxes that were not expected on such an experimental&amp;nbsp;testbed supposed to be connected to the Internet without any restriction.&lt;/p&gt;</style></abstract></record></records></xml>