Cisco Systems

De Kleetlaan 6a Diegem Belgium 1831 +32 2 778 4677 evyncke@cisco.com

Cisco Systems

De Kleetlaan 6a Diegem Belgium 1831 +32 2704 5473 gunter@cisco.com

v6ops Working Group I-D Internet-Draft IPv6 Traffic statistics During the Cisco European networkers Conference 2009 that ran from 26th to 29th January in Barcelona native IPv6 was added to the traditional IPv4 infrastructure. During this conference the 3500 attendees had dual stack access to both IPv4 and IPv6 simultaneously. The goal of this IPv6 deployment project was to gather usage statistics in a situation where the end-user just wants to access his/her enterprise VPN or simply get onto the Internet. The collected statistics are not only useful per se but this document presents easy ways to measure the quality of the IPv6 connectivity offered on such events. In essence the users were not conducting IPv6 technology tests, but were just using Internet services. The statistics collected give some pieces of information on the size and impact of IPv6 onto the normal userbase and will also derive the importance of IPv6 onto the infrastructiure and end-user operating systems and firewall technologies. The experiment ran in collaboration with Google and Tata-Communications .

Traditionally there is at this conference in Europe about 3500 attendees. The nature of the attendees is technical with a heavy focus on networkes and 90% will have a laptop but will not use them all the time (lack of time and lack of electrical power). The main elements the attendees expect from the network infrastructure is that its stable and easy accessible. The attendees use the network Infrastructure to access their enterprise network via a VPN and Internet content (hotels, restaurants, email, etc..). During the conference, about 10% of the users were made aware at the IPv6 session slots that IPv6 connectivity was available in native dual stack, however, the vast majority did not make special efforts to run IPv6 or even enable IPv6 on their end-user PC's. The experiment was run in three steps: (1) Networkers infrastructure was enabled for dual stack, (2) The local DNS server was white-listed by Google as content provider to give AAAA records for Google content and (3) the Router Advertisements were set to ask the users to use DHCPv6 for address configuration (M-flag) instead of IPv6 Stateless Address Autoconfiguration (SLAAC). Each of the steps was run with a lenght of 24 hours. This paper gives a summary insight in the statistics and the topology used for the IPv6 connectivity during each step. It also reports that everything kept working as expected and that the end-users were not aware they were using IPv6 as a foundation communication protocol in addition to IPv4: it was completely transparent for them.

The Network infrastructure at Cisco European Networkers conference is deployed in a four-storey building. For each floor has a dedicated routed IPv4 subnet available with a dedicated number of RFC 1918 IPv4 addresses. These addresses are translated at the edge of the network from private into a public address by a Network Address Translator. The wireless Access Points do also have smart services installed including end-system security (captive portal) and inter-AP roaming capability. For the IPv6 infrastructure, it was selected to create a single Layer-2 domain for the full Networkers conference spanning all 4 floors. In contrast, the number of stations per floor is not an issue with an IPv6 /64 subnet. This made the IPv6 deployment more simpler, eventhough it was needed to add some Ethernet protocol type filtering in place at the layer 2 of the OSI layer to separate IPv4 from IPv6: on the same topology (4 wireless LAN), there was both a 4 IPv4 subnets and a single IPv6 subnet. At the edge of network, an IPv6 router provided IPv6 connectivity through an IPv6-in-IPv4 tunnel to Tata Communication POP in Paris. Note: initially we were planning for a real native dual-stack connectivity over the local loop, but it appeared a too costly option when only a very small incremental budget is available (like almost 0 USD incremental cost). It was because of the kind sponsorship of Tata Communications that IPv6 was made available at zero incremental cost involved towards the conference leadership. To gather statistics from the deployment Netflow v9 and SNMP were used as well as regular shell access to network equipments. For the management, an old laptop was used running a Linux distribution. The statistics and traffic data from the event can be found http://www.cisconetworkers6.com/. A graphical representation of the topology can be found at http://www.cisconetworkers6.com/network/. The same Linux laptop run a DNS server and was offering the statistics over HTTP access. All HTTP accesses were logged including the User-Agent header in order to collect statistics about the browser and the operating system. The HTTP 64 aware technique was also used to force stations to bypass the address selection policy and use IPv6. The Following applications were used as supporting infrastructure: (1) MRTG (SNMP poll) , (2) NFsen (supporting Netflow v9 with IPv6 support) , (3) NDPMON (to monitor ND activities) , (4) RAMOND (to monitor RA activities) , DHCPv6 Server (Cisco IOS DHCPv6 Server).

Monday 26th of January 9:00: the MRTG & Netflow collector are connected to the Network; Tuesday 27th in the late afternoon, Google applies the DNS-trick and starts serving A & AAAA to all laptops using the local DNS server (only announced over DHCPv6) Wednesday 28th in the morning, the local DHCPv4 also serves a Google-trick-enabled DNS servers to all DHCPv4 clients, i.e., all laptops actually received the A and AAAA for Google Wednesday 28th 16:00, Router Advertisements include the M-flag for a few minutes; Thursday 29th 9:0, RA includes the M-flag all day; Thursday 29th 14:00, RA prefix is advertised with a calendar lifetime to 16:15; Thursday 29th 16:15, no more IPv6 traffic (thanks to RA prefix expiration), the router & collector are removed from the site;

The RTT was measured with ICMP echo requests & replies to www.google.com and www.6net.org over IPv6. In general the time to google remained constant from the conference (65 msec), while the RTT to 6net was lower 50% until the AAAA to Google was enabled (potentially due to higher IPv6 traffic load?). The RTT to Google was also measured over IPv4 (average 64 msec, peak 218 msec) and IPv6 (average 65 msec, peak 72 msec). The use of a 6-in-4 tunnel was not really impacting the latency to access Google if we assume that ICMP is a good measurement methodology.

What can be seen in the graphs at http://www.cisconetworkers6.com/mrtg/tunnel.html for the 6-in-4 tunnel is that there was a continuous growth in IPv6 traffic. There was many less people on Monday than on the rest of the week due to the conference organization and agenda. Monday the inbound traffic (Internet to the conference) was around 100kbps, Tuesday 400kbps, Wednesday 1.5Mbps and Thursday also around 1.5 Mbps. Outbound (conference to the Internet) can be seen for the 6-in-4 tunnel; there was also ongoing growth in IPv6 traffic. Monday the traffic was low and around 10kbps, Tuesday 50kbps, Wednesday 100kbps and Thursday also around 100kbps.

Details to be found at http://www.cisconetworkers6.com/mrtg/dhcpv6.html. From day 1, the Cisco IOS router was configured as a DHCPv6 IA server. However, only from Wednesday onwards, the M-bit was set in the Router Advertisements. This setting had a very interresting result because it made the number of DHCPv6 assigned addresses grow from 4 to a total 151 systems using DHCPv6 IPv6 address allocation. This is a clear indication that there were only 4 laptops with a IPv6 stack always trying to use statefull DHCPv6 while the vast majority of the laptops were only using RA for SLAAC. It can be assumed that the majority of the laptops were running Microsoft Windows XP or Vista.

Details regarding the amount of IPv6 neighbors of the router can be found at http://www.cisconetworkers6.com/mrtg/neighbours.html. The neighbors were split in two categories based on the IPv6 address: link-local or global addresses. A couple of interesting observations: the number of IPv6 neighbors grew on every single day during the conference, with a high peak on Wednesday 28th January. many systems had IPv6 enabled (555 stations) as seen by the Link-local neighborships, however at maximum 358 were actually using IPv6 to access the Internet. the number of link-local neighbors was similar on all days (except on Monday because there were less attendees). But, the number of global address neighbors changed dramatically on Wednesday morning when the AAAA for Google was served: it doubled from 180 to 358.

The traffic of DNS requests was also measured: 6 DNS requests/sec over IPv4 and 2 DNS requets/sec over IPv6. This is probably linked to the OS used on the laptops where the majority was probably Windows XP which only use IPv4 for DNS access.

In order to collect operating system information of the attendees, a challenge was announced in order to attract users on a dual-stack web server. Based on the number of attendees and the number of IPv6 neighbors, it is clear that the number of visitors (about 100) was only a small parts of the local IPv6 hosts (about 555) or even attendees (about 3,500). IPv6-enabled visitors: 20 *nix, 20 Microsoft Windows XP, 16 Microsoft Windows CE (smart-phones), 16 Apple Mac OS/X, 13 Microsoft Windows Vista, 6 Symbian (smart-phones) IPv4-only visitors: 70 Microsoft Windows XP, 13 Apple Mac OS/X, 9 Windows Vista and 25 *nic

Based on Netflow information, some data-points were collected over the 4 days: The IPv6 protocols: 84% for TCP, 10% for ICMPv6, the rest (7%) for UDP. There were also a very small amount of IPv6 datagrams with 59 (No Next Header for IPv6): 73 packets on a total of more than 8.7 millions. The layer-4 ports: 31% for NNTP, 30% for HTTP, 11% for SSH, 5% for HTTPS, 3% for DNS. The rest was not clearly identified. This may not be statiscally significant, but, the HTTP traffic went from 22% to 42% as soon as the AAAA for Google was served. The Internet hosts: 31% for 2001:888::119 (newszilla6.xs4all.nl), 7% for 2001:4860:0:1001::68 (Google), 5% for 2001:4860:0:1001::53 (Google), 5% for a site in the .NO domain, 5% for a site in the .SE domain, 2% for a site in a .CZ domain (as the addresses seem to relate to a non-public site, the authors preferred to keep those addresses non-public as well).

RAMOND and NDPMON detected not a single attack against the Neighbor Discovery Protocol.

A couple of areas for improvement have been identified after the experiment: Compare the Netflow information for IPv4 and IPv6. Collect information about all the operating systems (both IPv4 and IPv6), this could be done by sniffing the HTTP traffic and collecting the User-Agent. This measurement will probably require some legal advice in some countries...

There are no extra IANA consideration for this document.

There are no extra Security consideration for this document.

Many thanks go to Tata Communications and Yves Poppe for the sponsorship of the IPv6 Connectivity. We would also like to thank Erik Kline and Lorenzo Colitti from Google to have supported the deployment to enable AAAA DNS records for the Networkers Conference. All of this experimenting would not of been possible without the help from Cisco Networkers NOC team under leadership of Andy Phillips.