<?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%">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>